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About this book 


This is a book on the functional paradigm in general. We'll use the world's most popular functional programming language: 
JavaScript. Some may feel this is a poor choice as it's against the grain of the current culture which, at the moment, feels 
predominately imperative. However, | believe it is the best way to learn FP for several reasons: 


e You likely use it every day at work. 


This makes it possible to practice and apply your acquired knowledge each day on real world programs rather than pet 
projects on nights and weekends in an esoteric FP language. 


e We don't have to learn everything up front to start writing programs. 


In a pure functional language, you cannot log a variable or read a DOM node without using monads. Here we can 
cheat a little as we learn to purify our codebase. It's also easier to get started in this language since it's mixed 
paradigm and you can fall back on your current practices while there are gaps in your knowledge. 
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e The language is fully capable of writing top notch functional code. 


We have all the features we need to mimic a language like Scala or Haskell with the help of a tiny library or two. 
Object-oriented programming currently dominates the industry, but it's clearly awkward in JavaScript. It's akin to 
Camping off of a highway or tap dancing in galoshes. We have to bind all over the place lest this change out from 
under us, we don't have classes(Yet), we have various work arounds for the quirky behavior when the new keyword is 
forgotten, private members are only available via closures. To a lot of us, FP feels more natural anyways. 


That said, typed functional languages will, without a doubt, be the best place to code in the style presented by this book. 
JavaScript will be our means of learning a paradigm, where you apply it is up to you. Luckily, the interfaces are 
mathematical and, as such, ubiquitous. You'll find yourself at home with swiftz, scalaz, haskell, purescript, and other 
mathematically inclined environments. 


Gitbook (for a better reading experience) 


e Read it online 
e Download EPUB 
e Download Mobi (Kindle) 


Do it yourself 


git clone https://github.com/DrBoolean/mostly-adequate-guide.git 


cd mostly-adequate-guide/ 
npm install gitbook-cli -g 
gitbook init 


brew update 
brew cask install calibre 


gitbook mobi . ./functional.mobi 


Table of Contents 


See SUMMARY.md 


Contributing 


See CONTRIBUTING.md 


Translations 


See TRANSLATIONS.md 


Plans for the future 


e Part 1 is a guide to the basics. I'm updating as | find errors since this is the initial draft. Feel free to help! 

e Part 2 will address type classes like functors and monads all the way through to traversable. | hope to squeeze in 
transformers and a pure application. 

e Part 3 will start to dance the fine line between practical programming and academic absurdity. We'll look at comonads, 
f-algebras, free monads, yoneda, and other categorical constructs. 
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Chapter 1: What ever are we doing? 


Introductions 


Hi I'm Professor Franklin Risby, pleased to make your acquaintance. We'll be spending some time together as I'm 
supposed to teach you a bit about functional programming. But enough about me, what about you? I'm hoping you're 
familiar with the JavaScript language, have a teensy bit of Object-Oriented experience, and fancy yourself a working class 
programmer. You don't need to have a Ph.D in Entomology, you just need to know how to find and kill some bugs. 


| won't assume any previous functional programming knowledge because we both know what happens when you assume, 
but | will expect you to have run into some of the unfavorable situations that arise from working with mutable state, 
unrestricted side effects, and unprincipled design. Now that we've been properly introduced, let's get on with it. 


The purpose of this chapter is to give you a feel for what we're after when we write functional programs. We must have 
some idea about what makes a program functional or we'll find ourselves scribbling aimlessly, avoiding objects at all costs - 
a clumsy endeavor indeed. We need a bullseye to hurl our code toward, some celestial compass for when the waters get 
rough. 


Now there are some general programming principles, various acronymic credos that guide us through the dark tunnels of 
any application: DRY (don't repeat yourself), loose coupling high cohesion, YAGNI (ya ain't gonna need it), principle of least 
surprise, single responsibility, and so on. 


| won't belabor listing each and every guideline I've heard throughout the years... the point is that they hold up ina 
functional setting, though they're merely tangential to our goal. Whaat I'd like you to get a feel for now, before we get any 
further, is our intention when we poke and prod at the keyboard; our functional Xanadu. 


A brief encounter 


Let's start with a touch of insanity. Here is a seagull application. When flocks conjoin they become a larger flock and when 
they breed they increase by the number of seagulls with whom they're breeding. Now this is not intended to be good 
Object-Oriented code, mind you, it is here to highlight the perils of our modern, assignment based approach. Behold: 


var Flock = function(n) { 
this.seagulls =n; 


Me 


Flock.prototype.conjoin = function(other) { 
this.seagulls += other.seagulls; 
return this; 


i 


Flock.prototype.breed = function(other) { 
this.seagulls = this.seagulls * other.seagulls; 
return this; 


VF 


var flock_a 
var flock_b 
var flock_c 


new Flock(#); 
new Flock(-); 
new Flock(*); 


var result = flock_a.conjoin(flock_c) 
.breed(flock_b).conjoin(flock_a.breed(flock_b)).seagulls; 


Who on earth would craft such a ghastly abomination? It is unreasonably difficult to keep track of the mutating internal 
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state. And, good heavens, the answer is even incorrect! It should have been 16 , but flock_a wound up permanently 
altered in the process. Poor flock_a. This is anarchy in the I.T.! This is wild animal arithmetic! 


If you don't understand this program, it's okay, neither do |. The point is that state and mutable values are hard to follow 
even in such a small example. 


Let's try again with a more functional approach: 


var conjoin = function(flock_x, flock_y) { return flock_x + flock_y }; 
var breed = function(flock_x, flock_y) { return flock_x * flock_y }; 


i 
S 


var flock_a 
var flock_b 
var flock_c = @Q; 


i 
RQ 
= 


var result = conjoin( 
breed(flock_b, conjoin(flock_a, flock c)), breed(flock a, flock_b) 
); 


Well, we got the right answer this time. There's much less code. The function nesting is a tad confusing...(we'll remedy this 
situation in ch5). It's better, but let's dig deeper. There are benefits to calling a spade a spade. Had we done so, we might 
have seen we're just working with simple addition ( conjoin ) and multiplication ( breed ). 


There's really nothing special at all about these two functions other than their names. Let's rename our custom functions to 
reveal their true identity. 


var add = function(x, y) { return x + y }; 
var multiply = function(x, y) { return x * y }; 


var flock_a = 4; 
var flock_b = 2; 
var flock_c = 0; 


var result = add( 
multiply(flock_b, add(flock_a, flock_c)), multiply(flock_a, flock_b) 
); 


And with that, we gain the knowledge of the ancients: 


Qo 0VULAaLAVO 


add(add(x, y), z) == add(x, add(y, z)); 


TIT) 9 
WU LaLa veo 


add(x, y) == add(y, x); 


identity 


add(x, ©) == x, 


GES ean Ue e 


multiply(x, add(y,z)) == add(multiply(x, y), multiply(x, z)); 


Ah yes, those old faithful mathematical properties should come in handy. Don't worry if you didn't Know them right off the 
top of your head. For a lot of us, it's been a while since we've reviewed this information. Let's see if we can use these 
properties to simplify our little seagull program. 


Pes pee ee ys 
UliQilidl LITE 


a 


add(multiply(flock_b, add(flock_a, flock c)), multiply(flock_a, flock_b)); 
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Uu t . 4uUul 


add(multiply(flock_b, flock_a), multiply(flock_a, flock_b)); 


Jay Uso Zl Ut av 


multiply(flock_b, add(flock_a, flock_a)); 


7» / LW QUINAC Y ws UI it 


Brilliant! We didn't have to write a lick of custom code other than our calling function. We include add and multiply 
definitions here for completeness, but there is really no need to write them - we surely have an add and multiply provided 
by some previously written library. 


You may be thinking "how very strawman of you to put such a mathy example up front". Or “real programs are not this 
Simple and cannot be reasoned about in such a way”. I've chosen this example because most of us already know about 
addition and multiplication so it's easy to see how math can be of use to us here. 


Don't despair, throughout this book, we'll sprinkle in some category theory, set theory, and lambda calculus to write real 
world examples that achieve the same simplicity and results as our flock of seagulls example. You needn't be a 
mathematician either, it will feel just like using a normal framework or api. 


It may come as a Surprise to hear that we can write full, everyday applications along the lines of the functional analog 
above. Programs that have sound properties. Programs that are terse, yet easy to reason about. Programs that don't 
reinvent the wheel at every turn. Lawlessness is good if you're a criminal, but in this book, we'll want to acknowledge and 
obey the laws of math. 


We'll want to use the theory where every piece tends to fit together so politely. We'll want to represent our specific problem 
in terms of generic, composable bits and then exploit their properties for our own selfish benefit. It will take a bit more 
discipline than the “anything goes" approach of imperative(We'll go over the precise definition of imperative later in the 
book, but for now it's anything other than functional programming) programming, but the payoff of working within a 
principled, mathematical framework will astound you. 


We've seen a flicker of our functional north star, but there are a few concrete concepts to grasp before we can really begin 
our journey. 


Chapter 2: First Class Functions 
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Chapter 2: First Class Functions 


A quick review 


When we say functions are "first class", we mean they are just like everyone else... so normal class(coach?). We can treat 
functions like any other data type and there is nothing particularly special about them - store them in arrays, pass them 
around, assign them to variables, what have you. 


That is JavaScript 101, but worth a mention as a quick code search on github will show the collective evasion, or perhaps 
widespread ignorance of the concept. Shall we go for a feigned example? We shall. 


var hi = function(name) { 
return "Hi " + name; 


ie 


var greeting = function(name) { 
return hi(name); 


ie 


Here, the function wrapper around hi in greeting is completely redundant. Why? Because functions are callable in 
JavaScript. When hi has the () atthe end it will run and return a value. When it does not, it simply returns the function 


Stored in the variable. Just to be sure, have a look-see: 


hi; 
hi("jonas"); 


Since greeting iS merely turning around and calling hi with the very same argument, we could simply write: 


var greeting = hi; 


greeting("times"); 


Hi times 


In other words, hi is already a function that expects one argument, why place another function around it that simply calls 
hi with the same bloody argument? It doesn't make any damn sense. It's like donning your heaviest parka in the dead of 


July just to blast the air and demand an ice lolly. 


It is obnoxiously verbose and, as it happens, bad practice to surround a function with another function merely to delay 
evaluation. (We'll see why in a moment, but it has to do with maintenance.) 


A solid understanding of this is critical before moving on, so let's see a few more fun examples excavated from npm 


modules. 


\ o 
2yitt GAatil 


var getServerStuff = function(callback){ 
return ajaxCall(function(json){ 
return callback(json); 
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}); 
3; 


enlightened 
var getServerStuff = ajaxCall; 


The world is littered with ajax code exactly like this. Here is the reason both are equivalent: 


this line 
return ajaxCall(function(json){ 
return callback(json); 


}); 


is the same as this line 
return ajaxCall(callback); 


getServerStuff 


var getServerStuff = function(callback){ 
return ajaxCall(callback) ; 


w aw 


}; 
//_...which is equivalent to this 
var getServerStuff = ajaxCall; // <-- look mum, no 


And that, folks, is how it is done. Once more then we'll see why I'm so insistent. 


var BlogController = (function() { 
var index = function(posts) { 
return Views.index(posts); 


}; 


var show = function(post) { 
rcturn Views.show(post); 


}; 


var create = function(attrs) { 
rcturn Db.create(attrs); 


}; 


var update = function(post, attrs) { 
rcturn Db.update(post, attrs); 


}; 


var destroy = function(post) { 
return Db.destroy(post); 


ie 


Fetura 4 
index: index, show: show, create: create, update: update, destroy: destroy 
}; 
0; 


This ridiculous controller is 99% fluff. We could either rewrite it as: 


var BlogController = { 
index: Views.index, 
show: Views. show, 
create: Db.create, 
update: Db.update, 
destroy: Db.destroy 


...OF SCrap it altogether as it does nothing other than bundle our Views and Db together. 
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Why favor first class? 


Okay, let's get down to the reasons to favor first class functions. As we saw in the getServerstuff and BlogController 
examples, it's easy to add layers of indirection that have no actual value and only increase the amount of code to maintain 
and search through. 


In addition, if a function we are needlessly wrapping does change, we must also change our wrapper function. 


httpGet('/post/2', function(json){ 
return renderPost(json); 


}); 
If httpGet were to change to send a possible err , we would need to go back and change the "glue". 


to ery 11 in the application and explicitly pass err 
Sf ALONG. 
httpGet('/post/2', function(json, err){ 
return renderPost(json, err); 


Di 


Had we written it as a first class function, much less would need to change: 


oT) ~ 75 , Lc 


- 1, eae : : = 
ende! a: ailed Within nttpGet with nowever many arguments 1T wants 


httpGet('/post/2', renderPost); 


Besides the removal of unnecessary functions, we must name and reference arguments. Names are a bit of an issue, you 
see. We have potential misnomers - especially as the codebase ages and requirements change. 


Having multiple names for the same concept is a common source of confusion in projects. There is also the issue of 
generic code. For instance, these two functions do exactly the same thing, but one feels infinitely more general and 
reusable: 


iin curre 


cat an g 
var validArticles = function(articles) { 
return articles. filter(function(article){ 
return article !== null && article !== undefined; 
}); 
}; 
Stly n an 
var compact = function(xs) { 
return xs.filter(function(x) { 
return x !== null && x !== undefined; 
}); 
}; 


By naming things, we've seemingly tied ourselves to specific data (in this case articles ). This happens quite a bit and is a 
source of much reinvention. 


| must mention that, just like with Object-Oriented code, you must be aware of this coming to bite you in the jugular. If an 
underlying function uses this and we call it first class, we are subject to this leaky abstraction's wrath. 


var fs = require('fs'); 
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fs.readFile('freaky friday.txt', Db.save); 


// less soa 
fs.readFile('freaky friday.txt', Db.save.bind(Db)); 


Having been bound to itself, the pb is free to access its prototypical garbage code. | avoid using this like a dirty nappy. 
There's really no need when writing functional code. However, when interfacing with other libraries, you'll have to acquiesce 
to the mad world around us. 


Some will argue this is necessary for speed. If you are the micro-optimization sort, please close this book. If you cannot 
get your money back, perhaps you can exchange it for something more fiddly. 


And with that, we're ready to move on. 


Chapter 3: Pure Happiness with Pure Functions 
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Chapter 3: Pure Happiness with Pure Functions 


Oh to be pure again 


One thing we need to get straight is the idea of a pure function. 


A pure function is a function that, given the same input, will always return the same output and does not have any 
observable side effect. 


Take slice and splice . They are two functions that do the exact same thing - in a vastly different way, mind you, but the 
same thing nonetheless. We say slice is pure because it returns the same output per input every time, guaranteed. 
splice , however, will chew up its array and spit it back out forever changed which is an observable effect. 


var xs = [4,2,3,4,8]; 
pure 
xs.slice(#,3); 
at eal 
xs.slice(8,3); 
[=> [1,2,3] 


xs.slice(0,3); 


: Fige 3 


/ impure 
xs.splice($,3); 


[a 2, 3] 


xs .splice(@,32); 


xs .splice(8,2); 


//=> [] 


In functional programming, we dislike unwieldy functions like splice that mutate data. This will never do as we're striving 
for reliable functions that return the same result every time, not functions that leave a mess in their wake like splice . 


Let's look at another example. 


‘ impure 


var minimum = 21; 


var checkAge = function(age) { 
return age >= minimum; 


}; 


/ (pure 
var checkAge = function(age) { 
var minimum = 21; 
return age >= minimum; 


}; 


In the impure portion, checkage depends on the mutable variable minimum to determine the result. In other words, it 
depends on system state which is disappointing because it increases the cognitive load by introducing an external 
environment. 
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It might not seem like a lot in this example, but this reliance upon state is one of the largest contributors to system 
complexity(http://www.curtclifton.net/storage/papers/MoseleyMarksO6a.pdf). This checkage may return different results 
depending on factors external to input, which not only disqualifies it from being pure, but also puts our minds through the 
ringer each time we're reasoning about the software. 


Its pure form, on the other hand, is completely self sufficient. We can also make minimum immutable, which preserves the 
purity as the state will never change. To do this, we must create an object to freeze. 


var immutableState = Object.freeze({ 
minimum: 21 


bs 


Side effects may include... 


Let's look more at these "side effects” to improve our intuition. So what is this undoubtedly nefarious side effect mentioned 
in the definition of pure function? We'll be referring to effect as anything that occurs in our computation besides the 
calculation of a result. 


There's nothing intrinsically bad about effects and we'll be using them all over the place in the chapters to come. It's that 
side part that bears the negative connotation. Water alone is not an inherent larvae incubator, it's the stagnant part that 
yields the swarms, and | assure you, side effects are a similar breeding ground in your own programs. 


A side effect is a change of system state or observable interaction with the outside world that occurs during the 
calculation of a result. 


Side effects may include, but are not limited to 


e changing the file system 

e inserting a record into a database 
e making an http call 

e mutations 

e printing to the Screen / logging 

e obtaining user input 

e querying the DOM 

e accessing system state 


And the list goes on and on. Any interaction with the world outside of a function is a side effect, which is a fact that may 
prompt you to suspect the practicality of programming without them. The philosophy of functional programming postulates 
that side effects are a primary cause of incorrect behavior. 


It is not that we're forbidden to use them, rather we want to contain them and run them in a controlled way. We'll learn how 
to do this when we get to functors and monads in later chapters, but for now, let's try to keep these insidious functions 
separate from our pure ones. 


Side effects disqualify a function from being pure and it makes sense: pure functions, by definition, must always return the 
Same output given the same input, which is not possible to guarantee when dealing with matters outside our local function. 


Let's take a closer look at why we insist on the same output per input. Pop your collars, we're going to look at some 8th 
grade math. 


8th grade math 
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From mathisfun.com: 
A function is a special relationship between values: Each of its input values gives back exactly one output value. 


In other words, it's just a relation between two values: the input and the output. Though each input has exactly one output, 
that output doesn't necessarily have to be unique per input. Below shows a diagram of a perfectly valid function from x to 


y; 


X y 





(http://www.mathsisfun.com/sets/function.html) 


To contrast, the following diagram shows a relation that is not a function since the input value 5 points to several outputs: 


x y 





(http:/Awww.mathsisfun.com/sets/function.html) 


Functions can be described as a Set of pairs with the position (input, output): [(1,2), (3,6), (5,16)] (It appears this 
function doubles its input). 


Or perhaps a table: 


Input Output 
1 2 
2 4 
3 6 


Or even as a graph with x as the input and y as the output: 
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There's no need for implementation details if the input dictates the output. Since functions are simply mappings of input to 
output, One could simply jot down object literals and run them with [] instead of (). 


var toLowerCase = {AUT a' WR. See Lull Ge He ies eu te", Mpls "d"}; 


toLowerCase['"C']; 


var isPrime = {l:fals®, 2: true, 3: true, 4: false, 5: true, 6:false}; 


isPrime[ ]; 
/=> true 


Of course, you might want to calculate instead of hand writing things out, but this illustrates a different way to think about 
functions.(You may be thinking "what about functions with multiple arguments?". Indeed, that presents a bit of an 
inconvenience when thinking in terms of mathematics. For now, we can bundle them up in an array or just think of the 
arguments Object as the input. When we learn about currying, we'll see how we can directly model the mathematical 
definition of a function.) 


Here comes the dramatic reveal: Pure functions are mathematical functions and they're what functional programming is all 
about. Programming with these little angels can provide huge benefits. Let's look at some reasons why we're willing to go to 
great lengths to preserve purity. 


The case for purity 


Cacheable 


For starters, pure functions can always be cached by input. This is typically done using a technique called memoization: 


var squareNumber = memoize(function(*){ return x*x; }); 


squareNumber(. ); 


CTS el a 


squareNumber(#); // returns 


& 


6 


SquareNumber(_); 


%E 
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squareNumber(_ ); 


96 


Here is a simplified implementation, though there are plenty of more robust versions available. 


var memoize = function(f) { 
var cache = {}; 


return function() { 
var arg_str = JSON.stringify(arguments); 
cache[arg_str] = cache[arg_str] || f.apply(f, arguments); 
return cache[arg_str]; 
}; 
}; 


Something to note is that you can transform some impure functions into pure ones by delaying evaluation: 


var pureHttpCall = memoize(function(url, params) { 
return function() { return $.getJSON(url, params); } 
}); 


The interesting thing here is that we don't actually make the http call - we instead return a function that will do so when 
called. This function is pure because it will always return the same output given the same input: the function that will make 
the particular http call given the url and params . 


Our memoize function works just fine, though it doesn't cache the results of the http call, rather it caches the generated 
function. 


This is not very useful yet, but we'll soon learn some tricks that will make it so. The takeaway is that we can cache every 
function no matter how destructive they seem. 


Portable / Self-Documenting 


Pure functions are completely self contained. Everything the function needs is handed to it on a silver platter. Ponder this 
for a moment... How might this be beneficial? For starters, a function's dependencies are explicit and therefore easier to 
see and understand - no funny business going on under the hood. 


impure 
var signup = function(attrs) { 


var user = SaveUser(attrs); 
we lcomeUser (user); 


); 


var signUp = function(Db, Email, attrs) { 
return function() { 
var user = saveUser(Db, attrs); 
welcomeUser(Email, user); 


ie 
tes 


The example here demonstrates that the pure function must be honest about its dependencies and, as such, tell us exactly 
what it's up to. Just from its signature, we know that it will use a Db , Email , and attrs which should be telling to say the 
least. 


We'll learn how to make functions like this pure without merely deferring evaluation, but the point should be clear that the 
pure form is much more informative than its sneaky impure counterpart which is up to God knows what. 
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Something else to notice is that we're forced to "inject" dependencies, or pass them in as arguments, which makes our app 
much more flexible because we've parameterized our database or mail client or what have you(Don't worry, we'll see a way 
to make this less tedious than it sounds). Should we choose to use a different Db we need only to call our function with it. 
Should we find ourselves writing a new application in which we'd like to reuse this reliable function, we simply give this 
function whatever pb and email we have at the time. 


In a JavaScript setting, portability could mean sSerializing and sending functions over a socket. It could mean running all our 
app code in web workers. Portability is a powerful trait. 


Contrary to “typical” methods and procedures in imperative programming rooted deep in their environment via state, 
dependencies, and available effects, pure functions can be run anywhere our hearts desire. 


When was the last time you copied a method into a new app? One of my favorite quotes comes from Erlang creator, Joe 
Armstrong: "The problem with object-oriented languages is they've got all this implicit environment that they carry around 
with them. You wanted a banana but what you got was a gorilla holding the banana... and the entire jungle”. 


Testable 


Next, we come to realize pure functions make testing much easier. We don't have to mock a "real" payment gateway or 
setup and assert the state of the world after each test. We simply give the function input and assert output. 


In fact, we find the functional community pioneering new test tools that can blast our functions with generated input and 
assert that properties hold on the output. It's beyond the scope of this book, but | strongly encourage you to search for and 
try Quickcheck - a testing tool that is tailored for a purely functional environment. 


Reasonable 


Many believe the biggest win when working with pure functions is referential transparency. A spot of code is referentially 
transparent when it can be substituted for its evaluated value without changing the behavior of the program. 


Since pure functions always return the Same output given the same input, we can rely on them to always return the same 
results and thus preserve referential transparency. Let's see an example. 


var Immutable = require("immutable"); 


var decrementHP = function(player) { 
return player.set("hp", player.get("hp")-2); 
}; 


var isSameTeam = function(playeri1, player2) { 
return playeri.get("team") === player2.get("team"); 


}; 


var punch = function(player. target) { 
if (isSameTeam(player, target)) { 
rctunm target: 
} else { 
return decrementHP(target ); 


} 
}; 


var jobe = Immutable.Map({name:"Jobe", hp:20, team: "red"}); 
var michael = Immutable.Map({name:"Michael", hp:20, team: "green"}); 


punch(jobe, michael); 


4 oo sina c® 1 ~ Vt Goes ne " my 
bab eS ap ( qflallle J => ae ry nls yg 3) 


decrementHP , isSameTeam and punch are all pure and therefore referentially transparent. We can use a technique called 
equational reasoning wherein one substitutes "equals for equals" to reason about code. It's a bit like manually evaluating 
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the code without taking into account the quirks of programmatic evaluation. Using referential transparency, let's play with 
this code a bit. 


First we'll inline the function isSameTeam . 


var punch = function(player, target) { 


if (player.get("team") === target.get("team")) { 
return target, 

} else { 
return decrementHP(target); 

} 


}; 
Since our data is immutable, we can simply replace the teams with their actual value 


var punch = function(player, target) { 
if ("red" === "green") { 
return target; 
Verse, 
return decrementHP(target); 


} 
}; 


We see that it is false in this case so we can remove the entire if branch 


var punch = function(player, target) { 
return decrementHP(target ); 


}; 
And if we inline decrementup , we See that, in this case, punch becomes a call to decrement the hp by 1. 


var punch = function(player, target) { 
FeLuUrNetargek.seL( Np 7 tangebegert mp \-—L)e 
}; 


This ability to reason about code is terrific for refactoring and understanding code in general. In fact, we used this technique 
to refactor our flock of seagulls program. We used equational reasoning to harness the properties of addition and 
multiplication. Indeed, we'll be using these techniques throughout the book. 


Parallel Code 


Finally, and here's the coup de grace, we can run any pure function in parallel since it does not need access to shared 
memory and it cannot, by definition, have a race condition due to some side effect. 


This is very much possible in a server side js environment with threads as well as in the browser wth web workers though 
current culture Seems to avoid it due to complexity when dealing with impure functions. 


In Summary 


We've seen what pure functions are and why we, as functional programmers, believe they are the cat's evening wear. From 
this point on, we'll strive to write all our functions in a pure way. We'll require some extra tools to help us do so, but in the 
meantime, we'll try to Separate the impure functions from the rest of the pure code. 
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Writing programs with pure functions is a tad laborious without some extra tools in our belt. We have to juggle data by 
passing arguments all over the place, we're forbidden to use state, not to mention effects. How does one go about writing 
these masochistic programs? Let's acquire a new tool called curry. 


Chapter 4: Currying 
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Chapter 4: Currying 


Can't live if livin' is without you 


My Dad once explained how there are certain things one can live without until one acquires them. A microwave is one such 


thing. Smart phones, another. The older folks among us will remember a fulfilling life sans internet. For me, currying is on 
this list. 


The concept is simple: You can call a function with fewer arguments than it expects. It returns a function that takes the 
remaining arguments. 


You can choose to call it all at once or simply feed in each argument piecemeal. 


var add = function(x) { 
return function(y) { 
return x + y, 


ne 
3 


var increment = add(‘); 
var addTen = add(19); 


increment(.); 


addTen(. ); 


ae 


Here we've made a function add that takes one argument and return a function. By calling it, the returned function 
remembers the first argument from then on via the closure. Calling it with both arguments all at once is a bit of a pain, 
however, So we can use a special helper function called curry to make defining and calling functions like this easier. 


Let's Setup a few curried functions for our enjoyment. 


var curry = requir®('lodash.curry'); 


var match = curry(function(what, str) { 
return str.match(what); 


}); 


var replace = curry(function(what, replacement, str) { 
return str.replace(what, replacement); 


}); 


var filter = curry(function(f, ary) { 
return ary.filter(f); 
}); 


var map = curry(function(f, ary) { 


return ary.map(f); 


}); 


The pattern I've followed is a simple, but important one. I've strategically positioned the data we're operating on (String, 
Array) as the last argument. It will become clear as to why upon use. 


match(/\s+/g, "hello world"); 
ie 
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match(/\s+/g)("hello world"); 
aL) 


var hasSpaces = match(/\s+/g); 


4 


-eturn x.match( } 


TUNCTLON| X } 


hasSpaces("hello world"); 
b al 
hasSpaces("spaceless"); 


nu ll 


filter(hasSpaces, [“tori_spelling", "tori amos"]); 
("tori ar | 


a 


var findSpaces = filter(hasSpaces) ; 


findSpaces(["tori_spelling", “tori amos"]); 


3 Am el 


var noVowels = replace(/[aeiau]/ig); 


function(replacement, x) { returt } 


var censored = noVowels("*"); 


er ar 


VLA ie a ! -py ac 


censored("Chocolate Rain"); 


ry a 


nr! 


What's demonstrated here is the ability to "pre-load" a function with an argument or two in order to receive a new function 
that remembers those arguments. 


| encourage you tO npm install lodash , copy the code above and have a go at it in the repl. You can also do this ina 
browser where lodash or ramda is available. 


More than a pun / special sauce 


Currying is useful for many things. We can make new functions just by giving our base functions some arguments as seen 


IN hasSpaces , findSpaces , and censored . 


We also have the ability to transform any function that works on single elements into a function that works on arrays simply 
by wrapping it with map : 


var getChildren = function(x) { 
return x.childNodes; 


}; 


var allTheChildren = map(getChildren); 


Giving a function fewer arguments than it expects is typically called partial application. Partially applying a function can 
remove a lot of boiler plate code. Consider what the above allTheChildren function would be with the uncurried map from 
lodash(note the arguments are in a different order): 


var allTheChildren = function(elements) { 
return _.map(elements, getChildren); 


}; 


We typically don't define functions that work on arrays, because we can just call map(getChildren) inline. Same with sort , 
filter , and other higher order functions(Higher order function: A function that takes or returns a function). 
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When we spoke about pure functions, we said they take 1 input to 1 output. Currying does exactly this: each single 
argument returns a new function expecting the remaining arguments. That, old sport, is 1 input to 1 output. 


No matter if the output is another function - it qualifies as pure. We do allow more than one argument at a time, but this is 
seen as merely removing the extra () 's for convenience. 


In summary 


Currying is handy and | very much enjoy working with curried functions on a daily basis. It is a tool for the belt that makes 
functional programming less verbose and tedious. 


We can make new, useful functions on the fly simply by passing in a few arguments and as a bonus, we've retained the 
mathematical function definition despite multiple arguments. 


Let's acquire another essential tool called compose . 


Chapter 5: Coding by Composing 


Exercises 


A quick word before we start. We'll use a library called ramda which curries every function by default. Alternatively you may 
choose to use /odash-fp which does the same and is written/maintained by the creator of lodash. Both will work just fine 
and it is a matter of preference. 


ramda lodash-fp 


There are unit tests to run against your exercises as you code them, or you can just copy-paste into a javascript REPL for 
the early exercises if you wish. 


Answers are provided with the code in the repository for this book 


var _ = require('ramda'); 


all < UME > DY Pdartild y ippLying The function 


var words = function(str) { 
Retro, Splte( se str). 


}; 


var sentences = undefined; 


Refactor to remove all men 11 


yee J Pw & aiiay appliyt es | 


var filterQs = function(xs) { 
return _.filter(function(x){ return match(/q/i, x); }, xs); 


}; 


if al QgumMents 
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77 “UEAVE VBE: 
var _keepHighest = function(x,y){ return x >= y?x : y; }; 


// REFACTOR THIS ONE: 
var max = function(xs) { 
return _.reduce(function(acc, x){ 
return _keepHighest(acc, x); 
}) -Infiniey,. xs); 
}; 


// Bonus 1: 

Ns 

// wrap array's slice to be functional and curried. 
thar (lees es ice (Ore) 

var slice = undefined; 


// Bonus 2: 

(i 2 =—===—=-— === 

// use slice to define a function "take" that takes n elements from the beginning of the string. Make it curried 
// // Result for "Something" with n=4 should be "Some" 

var take = undefined; 
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Chapter 5: Coding by Composing 


Functional husbandry 


Here's compose : 


var compose = function(f,g) { 
return function(x) { 

return f(g(x)); 

}; 

hi 


f and g are functions and x is the value being "piped" through them. 


Composition feels like function husbandry. You, breeder of functions, select two with traits you'd like to combine and mash 
them together to spawn a brand new one. Usage is as follows: 


var toUpperCase = function(x) { return x.toUpperCase(); }; 
var exclaim = function(x) { return x + es 
var shout = compose(exclaim, toUpperCase); 


shout("send in the clowns"); 


Neocnn rT . " 


The composition of two functions returns a new function. This makes perfect Sense: composing two units of some type (in 
this case function) should yield a new unit of that very type. You don't plug two legos together and get a lincoln log. There is 
a theory here, some underlying law that we will discover in due time. 


In our definition Of compose , the g willrun before the f , creating a right to left flow of data. This is much more readable 
than nesting a bunch of function calls. Without compose, the above would read: 


var shout = function(> ){ 
return exclaim(toUpperCase(x)); 


}; 


Instead of inside to outside, we run right to left, which | Suppose is a step in the left direction(boo). Let's look at an example 
where sequence matters: 


var head = function(x) { return x[0]; }; 
var reverse = reduce(function(acc, x){ return [x].concat(acc); }, []); 
var last = compose(head, reverse); 


last(['jumpkick', '‘roundhouse', ‘uppercut']); 


RRO 


reverse Will turn the list around while head grabs the initial item. This results in an effective, albeit inefficient, last 
function. The sequence of functions in the composition should be apparent here. We could define a left to right version, 
however, we mirror the mathematical version much more closely as it stands. That's right, composition is straight from the 
math books. In fact, perhaps it's time to look at a property that holds for any composition. 
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var associative = compose(f, compose(g, h)) == compose(compose(f, g), h); 


Composition is associative, meaning it doesn't matter how you group two of them. So, should we choose to uppercase the 
String, we can write: 


compose(toUpperCase, compose(head, reverse)); 


are: or 


compose(compose(toUpperCase, head), reverse); 


Since it doesn't matter how we group our calls to compose , the result will be the same. That allows us to write a variadic 
compose and use it as follows: 


previously we'd have to write two composes, but since 


var lastUpper = compose(toUpperCase, head, reverse); 


lastUpper(['jumpkick', ‘roundhouse', ‘uppercut']); 


var loudLastUpper = compose(exclaim, toUpperCase, head, reverse) 


loudLastUpper(['jumpkick', ‘roundhouse', ‘uppercut']); 


1IDDI { t 


FOMUL 


‘| t | 


) nnn eee, ne,ee,,,,,S SSS eee ommend 


Applying the associative property gives us this flexibility and peace of mind that the result will be equivalent. The slightly 
more complicated variadic definition is included with the support libraries for this book and is the normal definition you'll find 
in libraries like lodash, underscore, and ramda. 


One pleasant benefit of associativity is that any group of functions can be extracted and bundled together in their very own 
composition. Let's play with refactoring our previous example: 


var loudLastUpper = compose(exclaim, toUpperCase, head, reverse); 


var last = compose(head, reverse); 
var loudLastUpper = compose(exclaim, toUpperCase, last); 


var last = compose(head, reverse); 
var angry = compose(exclaim, toUpperCase); 
var loudLastUpper = compose(angry, last); 


There's no right or wrong answers - we're just plugging our legos together in whatever way we please. Usually it's best to 
group things in a reusable way like last and angry . If familiar with Fowler's "Refactoring", one might recognize this 
process as "extract method"...except without all the object state to worry about. 


Pointfree 


Pointfree style means never having to say your data. Excuse me. It means functions that never mention the data upon 
which they operate. First class functions, currying, and composition all play well together to create this style. 
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rf pol rre ecaus mention 


var snakeCase = function (word) { 


return word.toLowerCase().replace(/\st/ig, ' '); 
); 
//point free 
var snakeCase = compose(replace(/\s+/ig, ' '), toLowerCase); 


See how we partially applied replace ? What we're doing is piping our data through each function of 1 argument. Currying 
allows us to prepare each function to just take its data, operate on it, and pass it along. Something else to notice is how we 
don't need the data to construct our function in the pointfree version, whereas in the pointful one, we must have our word 
available before anything else. 


Let's look at another example. 


//not pointfree because mention t data: na 
var initials = function (name) { 
return name.split(' ').map(compose(toUpperCase, head)).join('. '); 
}; 
var initials = compose(join('. ‘'), map(compose(toUpperCase, head)), split(' '‘)); 


initials("hunter stockton thompson"); 


Pointfree code can again, help us remove needless names and keep us concise and generic. Pointfree is a good litmus test 
for functional code as it let's us know we've got small functions that take input to output. One can't compose a while loop, 
for instance. Be warned, however, pointfree is a double edge sword and can sometimes obfuscate intention. Not all 
functional code is pointfree and that is O.K. We'll shoot for it where we can and stick with normal functions otherwise. 


Debugging 
A common mistake is to compose something like map , a function of two arguments, without first partially applying it. 


wrong - we end up giving angry an array and 


var latin = compose(map, angry, reverse); 
latin(["frog", "eyes"]); 

reer 

right - each function expects argument. 


var latin = compose(map(angry), reverse); 


latin(["frog", "“eyes"]); 


fz it} t(('cponys | 
["EYES!", "FROG!"]) 


If you are having trouble debugging a composition, we can use this helpful, but impure trace function to see what's going 


on. 


Val trace = clirny(funetion( tag, x)4 
console.log(tag, x); 
reburn x: 


Is 
var dasherize = compose(join('-'), toLower, split(' '), replace(/\s{2,}/ig, ' ')); 


dasherize('The world is a vampire’); 
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Something is wrong here, let's trace 


var dasherize = compose(join('-'), toLower, trace("after split"), split(' '), replace(/\s{2,}/ig, | ')); 
after split [ 'The', ‘world’, ‘is’, ', 'vampire' ] 


Ah! We need to map this totower since it's working on an array. 


var dasherize = compase(join('-'), map(toLower), split(' '), replace(/\s{2,}/ig, ' ')); 
dasherize('The world is a vampire’); 


ri Amn - i 
G-1 ; amp1! 


The trace function allows us to view the data at a certain point for debugging purposes. Languages like haskell and 
purescript have similar functions for ease of development. 


Composition will be our tool for constructing programs and, as luck would have it, is backed by a powerful theory that 
ensures things will work out for us. Let's examine this theory. 


Category theory 


Category theory is an abstract branch of mathematics that can formalize concepts from several different branches such as 
set theory, type theory, group theory, logic, and more. It primarily deals with objects, morphisms, and transformations, which 
mirrors programming quite closely. Here is a chart of the same concepts as viewed from each separate theory. 


Types Logic Sets Homotopy 


A proposition set space 

a:A proof element point 

B(x) predicate family of sets fibration 

b(x) : Bix) conditional proof family of elements — section 

0,1 tle, 0,{@} ), * 

Oe c, AD disjoint union coproduct 
AX B AAB set of pairs product space 
AB A= B set of functions function space 
Yitx.ay BUX) 3.4 B(x) disjoint sum total space 
[T¢x:4) B(x) Vy 4 B(x) product space of sections 
Id equality = {(x,x)|x€A} — pathspace A! 


Sorry, | didn't mean to frighten you. | don't expect you to be intimately familiar with all these concepts. My point is to show 
you how much duplication we have so you can see why category theory aims to unify these things. 


In Category theory, we have something called... a category. It is defined as a collection with the following components: 
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e Acollection of objects 

e Acollection of morphisms 

e Anotion of composition on the morphisms 
e Adistinguished morphism called identity 


Category theory is abstract enough to model many things, but let's apply this to types and functions, which is what we care 
about at the moment. 


A collection of objects The objects will be data types. For instance, string , Boolean, Number , Object , etc. We often 
view data types as sets of all the possible values. One could look at Boolean as the set of [true, false] and Number as 
the set of all possible numeric values. Treating types as sets is useful because we can use set theory to work with them. 


A collection of morphisms The morphisms will be our standard every day pure functions. 


A notion of composition on the morphisms This, as you may have guessed, is our brand new toy - compose . We've 
discussed that our compose function is associative which is no coincidence as it is a property that must hold for any 
composition in category theory. 


Here is an image demonstrating composition: 


String 


compose (f, a) 


Boolean 
O 





Here is a concrete example in code: 


var g = function(x){ return x.length; }; 
Vaieet — tinecevonm(x){ rerurne x —-— 47.9) 
var isFourLetterWord = compose(f, g); 


A distinguished morphism called identity Let's introduce a useful function called id . This function simply takes some 
input and spits it back at you. Take a look: 


var id = function(x){ return x; }; 


You might ask yourself "What in the bloody hell is that useful for?". We'll make extensive use of this function in the following 
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chapters, but for now think of it as a function that can stand in for our value - a function masquerading as every day data. 


id must play nicely with compose. Here is a property that always holds for every unary(unary: a one argument function) 
function f: 


LUCTILAILY 


compose(id, f) == compose(f, id) == f; 


Hey, it's just like the identity property on numbers! If that's not immediately clear, take some time with it. Understand the 
futility. We'll be seeing id used all over the place soon, but for now we see it's a function that acts as a stand in for a given 
value. This is quite useful when writing pointfree code. 


So there you have it, a category of types and functions. If this is your first introduction, | imagine you're still a little fuzzy on 
what a category is and why it's useful. We will build upon this knowledge throughout the book. As of right now, in this 
chapter, on this line, you can at least See it as providing us with some wisdom regarding composition - namely, the 
associativity and identity properties. 


What are some other categories, you ask? Well, we can define one for directed graphs with nodes being objects, edges 
being morphisms, and composition just being path concatenation. We can define with Numbers as objects and >= as 
morphisms(actually any partial or total order can be a category). There are heaps of categories, but for the purposes of this 
book, we'll only concern ourselves with the one defined above. We have sufficiently skimmed the surface and must move 
on. 


In Summary 


Composition connects our functions together like a series of pipes. Data will flow through our application as it must - pure 
functions are input to output after all so breaking this chain would disregard output, rendering our software useless. 


We hold composition as a design principle above all others. This is because it keeps our app simple and reasonable. 
Category theory will play a big part in app architecture, modelling side effects, and ensuring correctness. 


We are now at a point where it would serve us well to see some of this in practice. Let's make an example application. 


Chapter 6: Example Application 


Exercises 


var _ = require('ramda'); 
var accounting = require('‘accounting'); 


// Example Data 

var CARS = [ 
{name: "Ferrari FF", horsepower: 660, dollar_value: 700000, in_stock: true}, 
{name: "Spyker C12 Zagato", horsepower: 650, dollar_value: 648000, in_stock: false}, 
{name: "Jaguar XKR-S", horsepower: 550, dollar_value: 132000, in_stock: false}, 
{name: "Audi R&8", horsepower: 525, dollar_value: 114200, in_stock: false}, 
{name: "Aston Martin One-77", horsepower: 750, dollar_value: 1850000, in_stock: true}, 
{name: "Pagani Huayra", horsepower: 700, dollar_value: 1300000, in_stock: false} 


Ie 


é us oJ o VWs d 2s at Tun 
var isLastInStack = function(cars) { 
var last_car = _.last(cars); 
return _.prop('in_stock', last_car); 
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hi 

// Exercise 2: 

= 

// use _.compose(), _.prop() and _.head() to retrieve the name of the first car 


var nameOfFirstCar = undefine; 


// Exercise 3: 


Use the helper function _average to refactor averageDollarValue as a composition 
var _average = function(xs) { return _.reduce(_.add, 8, xs) / xs.length; }; // <- leave be 


var averageDollarValue = function(cars) { 
var dollar_values = _.map(function(c) { return c.dollar_value; }, cars); 
return _average(dollar_values); 


}; 


‘/ Exercise 4: 


Write a function: sanitizeNames() using compose that returns a list of lowercase and underscored car's names: e.g: §s 


var _underscore = _,replace(/\Wt/g, ‘ ‘); //<-- leave this alone and use to sanitize 


var sanitizeNames = undefined; 


// Bonus 1: 
i 
// Refactor availablePrices with compose. 


var availablePrices = function(cars) { 
var available_cars = _.filter(_.prop('in_stock'), cars); 
return available_cars.map(function(*){ 
rcturn accounting. formatMoney(x.dollar_value); 
}).join(', '); 
}; 


// Bonus 2: 
== 


// Refactor to pointfree. Hint: you can use _.flip() 


var fastestCar = function(cars) { 


var sorted = _.sortBy(function(car){ return car.horsepower }, cars); 
var fastest = _,last(sorted); 
return fastest.name + ' is the fastest’; 

}; 


— ESE) ST ia 
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Chapter 6: Example Application 


Declarative coding 


We are going to switch our mindset. From here on out, we'll stop telling the computer how to do its job and instead write a 
specification of what we'd like as a result. I'm sure you'll find it much less stressful than trying to micromanage everything all 
the time. 


Declarative, as opposed to imperative, means that we will write expressions, as opposed to step by step instructions. 


Think of SQL. There is no "first do this, then do that". There is one expression that specifies what'd like from the database. 
We don't decide how to do the work, it does. When the database is upgraded and the SQL engine optimized, we don't have 
to change our query. This is because there are many ways to interpret our specification and achieve the same result. 


For some folks, myself included, it's hard to grasp the concept of declarative coding at first so let's point out a few examples 
to get a feel for it. 


/ imperative 

var makes = []; 

fom (i = Osi — cars lengeh; 1-4) 4 
makes.push(cars[i].make); 


} 


GgeClarat1lve 


var makes = cars.map(function(car){ return car.make; }); 


The imperative loop must first instantiate the array. The interpreter must evaluate this statement before moving on. Then it 
directly iterates through the list of cars, manually increasing a counter and showing its bits and pieces to us in a vulgar 
display of explicit iteration. 


The map version is one expression. It does not require any order of evaluation. There is much freedom here for how the 
map function iterates and how the returned array may be assembled. It specifies what, not how. Thus, it wears the shiny 
declarative sash. 


In addition to being clearer and more concise, the map function may be optimized at will and our precious application code 
needn't change. 


For those of you who are thinking "Yes, but it's much faster to do the imperative loop”, | suggest you educate yourself on 
how the JIT optimizes your code. Here's a terrific video that may shed some light 


Here is another example. 


var authenticate = function(form) { 
var user = toUser(form); 
return logIn(user); 


}y 


UoCwsAa! a ive 


var authenticate = compose(lagIn, toUser); 


Though there's nothing necessarily wrong with the imperative version, there is still an encoded step-by-step evaluation 
baked in. The compose expression simply states a fact: Authentication is the composition of touser and login . Again, this 
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leaves wiggle room for support code changes and results in our application code being a high level specification. 


Because we are not encoding order of evaluation, declarative coding lends itself to parallel computing. This coupled with 
pure functions is why FP is a good option for the parallel future - we don't really need to do anything special to achieve 
parallel/concurrent systems. 


A flickr of functional programming 


We will now build an example application in a declarative, composable way. We'll still cheat and use side effects for now, 
but we'll keep them minimal and separate from our pure codebase. We are going to build a browser widget that sucks in 
flickr images and displays them. Let's start by scaffolding the app. Here's the html: 


<!DOCTYPE html> 


<html> 
<head> 
<script src="https://cdnjs.cloudflare.com/ajax/libs/require. js/2.1.11/require.min.js"></script> 
<script src="flickr.js"></script> 
</head> 
<body></body> 
</html> 


And here's the flickr.js skeleton: 


requirejs.config({ 
paths: { 
ramda: ‘https://cdnjs.cloudflare.com/ajax/libs/ramda/0.13.0/ramda.min', 
jquery: ‘https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min' 
} 
}); 


require([ 
'ramda', 
'jJquery' 
], 
function Koes) f 


var trace = _.curry(function(tag, x) { 
console.log(tag, x); 
FetUunM xX; 
}); 
app g here 


ee 


We're pulling in ramda instead of lodash or some other utility library. It includes compose , curry , and more. I've used 
requirejs, which may seem like overkill, but we'll be using it throughout the book and consistency is key. Also, I've started us 
off with our nice trace function for easy debugging. 


Now that that's out of the way, on to the spec. Our app will do 4 things. 


1. Construct a url for our particular search term 
2. Make the flickr api call 

3. Transform the resulting json into html images 
4. Place them on the screen 


There are 2 impure actions mentioned above. Do you see them? Those bits about getting data from the flickr api and 
placing it on the screen. Let's define those first So we can quarantine them. 


var Impure =— { 
getJSON: _.curry(function(callback, url) { 
$.getJSON(url, callback); 
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}), 


setHtml: _.curry(function(sel, html) { 
$(sel).html(html); 


}) 
); 


Here we've simply wrapped jQuery's methods to be curried and we've swapped the arguments to a more favorable 
position. I've namespaced them with Impure so we know these are dangerous functions. In a future example, we will make 
these two functions pure. 


Next we must construct a url to pass to OUr Impure.getJson function. 


var url = function (term) { 
return ‘https://api.flickr.com/services/feeds/photos_public.gne?tags=' + 
term + ‘&format=json&jsoncallback=?'; 


H 


There are fancy and overly complex ways of writing url pointfree using monoids(we'll learn about these later) or 
combinators. We've chosen to stick with a readable version and assemble this string in the normal pointful fashion. 


Let's write an app function that makes the call and places the contents on the screen. 


var app = _.compose(Impure.getJSON(trace("response")), url); 


app("cats"); 


This calls our url function, then passes the string to our getjson function, which has been partially applied with trace . 
Loading the app will show the response from the api call in the console. 











eve Developer Tools - file-///Users/brian/Documents/ workahop/hardeare)a/damos/step 1 /Aickr.him| 
Q OD 1 Elements) Network Sources Timeline Profiles Resources Audits Console = @ Gl. 
Styles Computed Event Listeners » 
wehtml> ~ — 3 
& <head>_</head> element.style { + - @) 
TO DOG } 
</html> body { user agent stylesheet 


html 


Console | Search Emulation Rendering 


© YW <topframe> ¥ Preserve lag 


response flicke. 15:27 
v Object ftrtle: “Recent Uploads tagged cats", link: “Attp://www, flickr.com/photos/tags/cats/", description: » Mocrfied: "7615-85-947725:38: 252", generator: 
"nrepi/ Sw PLICKS.COm/s"..) 
description: °" 
generator: "nttp://www. flickr.com/'' 
wv items: Arcay(26) 

7: Object 
author: "nabody@flaickse.,cam (Pink Knitter)" 
author id: °"97637500eNee” 
date_taken: '"2015-@S-847@8: 38: 25-08: 80" 
description: | <p><a href="http: //wew. flickr.com/people/pinkknitter/">Pink Kmitter</a> posted a photo:</p> <p><a 
href="http://wwew. flickr. com/phatos/pinkknitter/17342800536/" tatle="Mosaic Monday - A new season has arrived''><img 
src2"http://farm.statieflickr, com/8698/17342880536_}3a2c@767d_m. jpg" width="192" height="'248" alt="Hasaic Monday - A mew seasan has arrived” /></a></p> <p>L 
<a href="http://fllekr.com/photos/482781932N@6/15891166163/">Drawing Cute Cats....#O, 2. <a 
hrefe"http://tlickr. cam/phovos/891789372NB7/17333037536/">_7500221-i</a>, 3. <a href="httpi//flickr. com/photos/26834791@N€B8/ 17123158727/">Pepper and his work 
of art in the backgraund from a week aga. 1 have yet to go to Ikea for a replacement. This was the last of ay favarite paper shades (pre-cats). Now I shop fo 
the cats.</a>, 4, «a href="http://flickr, com/photos/7828799QNO2/14572663159/">ICAD & 58 Romance</a>, 5. <a 
href="http://@lickr. com/photos/7820799AN82/16362784982/">Fantasy 11x14 canvase/a>, 6. <a href="http://flickr, com/phatos/6@138S@BQNGE / 1658426 3674/">Jess and 
Max</a>, 7. <a hrefe"htto://flickr. com/photos/32134444QN87/17291974625/">Raman</a>, 8. <a 
href="http://flickr. com/photos/138132341G@NO2/17197226821/">Untitled</a>, 9. <a href="nttp://flicks.com/photos/57686891@NB4/17131693295/">taoday ...</a>, 1@. — 
heef="httpi//flickr. com/photas/2974§ IBGQNEOS/ 17884147877/">new biby goats'</a>, 11. <a href="http://flicke.coa/phatas/891789379N87/16490577293/">Misty morning 
moonrise</a>, 12. «a href="http://flickr. com/photos/634859350NG4/16923728156/">milky way</a>, 13. <a 
hrefe"hrwtpi//FLACKr. Con/PhOtosS/ 3083467 3ANB3/17188712836/">Necdle Felted Dog Extra Large Exarple Maltese. Hello Spring.</a>, 14. <a 
href="httpi//tlickr. com/photos/29745 JBQ@@NBS/17162311725/">Llittle patchwork tags</a>, 15. <a 
href="hetp://flickr. con/photas/d0765196QNB5/16171280922/">Pomegranate dye fab-ic</a>, 16. <a href="http://flickr. com/photas/ 7868338 7QN@4/ 16473504466/">8B ila 
no ae Shs Fz </a>, 17. <a href='htto://flickr, com/photos/127734485QN83/155525459d6/">Pixel</a>, 18. <a 
href="http://tlickr. com/photos/866159S62NG6/ 16859761820/">Barcelona</a>, 19, <a href="http://flickr. com/photos/1308370820NG3/16614751858/">Tao coal</a>, 24. 
<a href="http://flickr.cam/photos/119353524NG5/1667510855S/">Lat Up Palms</a><br /> <br /> Created with <a href="http://bighugelabs.com" rel="nofallow'>fd's 
Flicker Toys</a></p>"' 
Link: “http://www. flickr. com/pholtos/pinkknitter/17342800536/" 

Vmedia: Object 
m: "hetar//farmo.staticflichr. com/8698/17342888536_13a2e8767d_mM. jpg" 
® proto: Objecr 
published: "2015-05-@4T2S: 38: 252" 
taqs: “trees cats sun art dogs words fdsflickrtoys kettles mosaicmonday” 
title: "Mosaic Monday - A new season has arrived" 
b : Object 


We'd like to construct images out of this json. It looks like the srcs are buried in items then each media 'S m property. 


Chapter 6: Example Application 34 





mostly-adequate-guide 


Anyhow, to get at these nested properties we can use a nice universal getter function from ramda called _.prop() . Here's a 
homegrown version so you can see what's happening: 


var prop = _.curry(function(property, object){ 
return object[property]; 


}); 


It's quite dull actually. We just use [] syntax to access a property on whatever object. Let's use this to get at our srcs. 


var mediaUrl = _.compose(_.prop('m'), _.prop('media')); 


var srcS = _.compose(_.map(mediaUrl), _.prop('items')); 


Once we gather the items ,we must map over them to extract each media url. This results in a nice array of srcs. Let's 
hook this up to our app and print them on the screen. 


var renderImages = _.compose(Impure.setHtml("body"), srcs); 
var app = _.compose(Impure.getJSON(renderImages), url); 


All we've done is make a new composition that will call our srcs and set the body html with them. We've replaced the 
trace Call with renderImages now that we have something to render besides raw json. This will crudely display our srcs 
directly in the body. 


Our final step is to turn these srcs into bonafide images. In a bigger application, we'd use a template/dom library like 
Handlebars or React. For this application though, we only need an img tag so let's stick with jQuery. 


var img = function (url) { 
return $('<img />', { src: url }); 


i 


jQuery's html() method will accept an array of tags. We only have to transform our srcs into images and send them along 
tO setHtml . 


var images = _.compose(_.map(img), srcs); 
var renderImages = _.compose(Impure.setHtml("body"), images); 
var app = _.compose(Impure.getJSON(renderImages), url); 


And we're done! 
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See asin . Bran 
= C@ A |) file:///Users/brian/Documents/workshop/hardcorejs/demos/step 1 fick: html 0 7 ‘a 9d @ocace 
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- we wr, 
htm! c= Styles | Computed Event Listeners ” 


Console |Search Emulation Rendering 


Here is the finished script: 


requirejs.config({ 
paths: { 
ramda: ‘https://cdnjs.cloudflare.com/ajax/libs/ramda/0.13.0/ramda.min', 
jquery: ‘https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min' 


} 
te 
require([ 
‘'ramda', 
‘jquery ' 


], 

Function (2, $)e 4 
VLAPLIITA SAHA TS AD TOTTI PI DII I PLAST IT 
// Urals 


var Impure = { 
getJSON: _.curry(function(callback, url) { 
$.getJSON(url, callback); 


}), 


setHtml: _.curry(function(sel, html) { 
$(sel) .html (html); 


}) 
ie 


var img = function (url) { 
return SC <1mg~/= "94 Srce Url })- 


}; 

Var Eface = curry (Tunction( tag, x) 4 
console.log(tag, x); 
return x; 

}); 


WISI ST PALIT LIAL AIA EPL LAA TATED FFD 


Val Un = funcerome (rE) 
return 'http://api.flickr.com/services/feeds/photos public.gne?tags=' + 
t + '&format=json&jsoncallback=?'; 


te 
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var mediaUrl = _.compose(_.prop('m'), _.prop('media')); 

var srcS = _.compose(_.map(mediaUrl), _.prop('items')); 

var images = _.compose(_.map(img), srcs); 

var renderImages = _.compose(Impure.setHtml('"body"), images); 
var app = _.compose(Impure.getJSON(renderImages), url); 


app("cats"); 


}); 


Now look at that. A beautifully declarative specification of what things are, not how they come to be. We now view each line 


as an equation with properties that hold. We can use these properties to reason about our application and refactor. 


A Principled Refactor 


There is an optimization available - we map over each item to turn it into a media url, then we map again over those srcs to 


turn them into img tags. There is a law regarding map and composition: 


map S composition law 
var law = compose(map(f), map(g)) == map(compose(f, g)); 


We can use this property to optimize our code. Let's have a principled refactor. 


| 4 


} 
4U4tIG2 UGCUUC 
J 


var mediaUrl = _.compose(_.prop('m'), _.prop( 'media')); 
var srcsS = _.compose(_.map(mediaUrl), _.prop( ‘items’ )); 
var images = _.compose(_.map(img), srcs); 


Let's line up our maps. We can inline the call to srcs in images thanks to equational reasoning and purity. 


var mediaUrl = _.compose(_.prop('m'), _.prop('media’' )); 


var images = _.campose(_.map(img), _.map(mediaUrl), _.prop('items')); 


Now that we've lined up our map ‘Ss we can apply the composition law. 


var mediaUrl = _.compose(_.prop('m'), _.prop( 'media' )); 


var images = _.compose(_.map(_.compose(img, mediaUrl)), _.prop('items')); 


Now the bugger will only loop once while turning each item into an img. Let's just make it a little more readable by 
extracting the function out. 


var mediaUrl = _.compose(_.prop('m'), _.prop( 'media' )); 
var mediaToImg = _.compose(img, mediaUrl); 
var images = _.compose(_.map(mediaToImg), _.prop('items')); 


Chapter 6: Example Application 


37 





mostly-adequate-guide 


In Summary 


We have seen how to put our new skills into use with a small, but real world app. We've used our mathematical framework 
to reason about and refactor our code. But what about error handling and code branching? How can we make the whole 
application pure instead of merely namespacing destructive functions? How can we make our app safer and more 
expressive? These are the questions we will tackle in part 2. 


Chapter 7: Hindley-Milner and Me 
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Hindley-Milner and Me 


What's your type? 


If you're new to the functional world, it won't be long before you find yourself knee deep in type signatures. Types are the 
meta language that enables people from all different backgrounds to communicate succinctly and effectively. For the most 
part, they're written with a system called "Hindley-Milner’, which we'll be examining together in this chapter. 


When working with pure functions, type signatures have an expressive power to which the English language cannot hold a 
candle. These signatures whisper in your ear the intimate secrets of a function. In a single, compact line, they expose 
behaviour and intention. We can derive "free theorems" from them. Types can be inferred so there's no need for explicit 
type annotations. They can be tuned to fine point precision or left general and abstract. They are not only useful for compile 
time checks, but also turn out to be the best possible documentation available. Type signatures thus play an important part 
in functional programming - much more than you might first expect. 


JavaScript is a dynamic language, but that does not mean we avoid types all together. We're still working with strings, 
numbers, booleans, and so on. It's just that there isn't any language level integration so we hold this information in our 
heads. Not to worry, since we're using signatures for documentation, we can use comments to serve our purpose. 


There are type checking tools available for JavaScript such as Flow or the typed dialect, TypeScript. The aim of this book is 
to equip one with the tools to write functional code so we'll stick with the standard type system used across FP languages. 


Tales from the cryptic 


From the dusty pages of math books, across the vast sea of white papers, amongst casual saturday morning blog posts, 
down into the source code itself, we find Hindley-Milner type signatures. The system is quite simple, but warrants a quick 
explanation and some practice to fully absorb the little language. 


: apitalize 55 LNG String 
var capitalize = function(s){ 
return toUpperCase(head(s)) + toLowerCase(tail(s)); 


i 


Capitalize("smurf"); 


Here, capitalize takeSa String andreturnS a string . Never mind the implementation, it's the type signature we're 
interested in. 


In HM, functions are written as a -> b where a and b are variables for any type. So the signatures for capitalize can be 
read as "a function from string to string ". In other words, it takes a String as its input and returns a String as its 
Output. 


Let's look at Some more function signatures: 


strLength :: String -> Number 
var strLength = function(s){ 
return s.length; 


} 


JOIN sStEing.-> [String] -—Sestring 


var join = curry(function(what, xs){ 
return xs.join(what ); 
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ir 


wid ott ' AC ej be x - 2 oOCL = L Cri sy ] 
var match = curry(function(reg, s){ 
return s.match(reg); 


ye 


lace :: R -> String -: na 
t wv 


var replace = curry(function(reg, sub, #){ 
return s.replace(reg, sub); 


)); 


strLength is the same idea as before: we take a string and return you a Number . 


The others might perplex you at first glance. Without fully understanding the details, you could always just view the last type 
as the return value. So for match you can interpret as: It takes a Regex anda string and returns you [string] . But an 
interesting thing is going on here that I'd like to take a moment to explain if | may. 


For match we are free to group the signature like so: 


match :: Re (String [Stri 


var match = curry(function(reg, s){ 
return s.match(reg); 


}); 


Ah yes, grouping the last part in parenthesis reveals more information. Now it is seen as a function that takes a Regex and 
returns us a function from string to [String] . Because of currying, this is indeed the case: give ita Regex and we geta 
function back waiting for its string argument. Of course, we don't have to think of it this way, but it is good to understand 
why the last type is the one returned. 


ONnMOLIWAY .. otF1iNng poCring | 


var onHoliday = match(/holiday/ig); 


Each argument pops one type off the front of the signature. onHoliday iS match that already has a Regex . 


lac ; Re (String 


var replace =- curry(function(reg, sub, s){ 
return s.replace(reg, sub); 


5 


As you can see with the full parenthesis on replace , the extra notation can get a little noisy and redundant so we simply 
omit them. We can give all the arguments at once if we choose so it's easier to just think of it as: replace takeS a Regex ,a 
String , another string and returns you a String. 


A few last things here: 


a a 


var id = function(x){ return x; } 
a Nar ad Se [b] 
var map = curry(function(f, xs){ 


return xs.map(f); 


}); 


The id function takes any old type a and returns something of the same type a. We're able to use variables in types just 


Chapter 7: Hindley-Milner and Me AO 





mostly-adequate-guide 


like in code. Variable names like a and b are convention, but they are arbitrary and can be replaced with whatever name 
you'd like. If they are the same variable, they have to be the same type. That's an important rule so let's reiterate: a -> b 
can be any type a to any type b, but a -> a means it has to be the same type. For example, id maybe string -> 
String Of Number -> Number , but not String -> Bool. 


map Similarly uses type variables, but this time we introduce b which may or may not be the same type as a. Wecan 
read it as: map takes a function from any type a to the same or different type b , then takes an array of a's and results in 
an array of b'S. 


Hopefully, you've been overcome by the expressive beauty in this type signature. It literally tells us what the function does 
almost word for word. It's given a function from a to b, anarray of a, and it delivers us an array of b. The only sensible 
thing for it to do is call the bloody function on each a. Anything else would be a bold face lie. 


Being able to reason about types and their implications is a skill that will take you far in the functional world. Not only will 
papers, blogs, docs, etc, become more digestible, but the signature itself will practically lecture you on its functionality. It 
takes practice to become a fluent reader, but if you stick with it, heaps of information will become available to you sans 
RTFMing. 


Here's a few more just to See if you can decipher them on your own. 


head wo [ a | 
var head = function(xs){ return xs['J; } 


filter = )(4,->,Boor) [a] -> 
var filter = curry(function(f, xs){ 
Ecturn xs, ftilter(t); 


}); 


educe A A ? a w } = > [a] UD 
var reduce = curry(function(f, x, x»){ 
return xs,reduce(f, x); 


1s 


reduce iS perhaps, the most expressive of all. It's a tricky one, however, so don't feel inadequate should you struggle with 
it. For the curious, I'll try to explain in English though working through the signature on your own is much more instructive. 


Ahem, here goes nothing....looking at the signature, we see the first argument is a function that expects a b,an a, and 
produces a b. Where might it get these as and bs? Well, the following arguments in the signature are a b and an array 
of asso wecan only assume that the b and each of those a Ss will be fed in. We also see that the result of the function is 
a b so the thinking here is our final incantation of the passed in function will be our output value. Knowing what reduce 
does, we can State that the above investigation is accurate. 


Narrowing the possibility 


Once a type variable is introduced, there emerges a Curious property called 
parametricity(http://en.wikipedia.org/wiki/Parametricity). This property states that a function will act on all types in a uniform 
manner. Let's investigate: 


Looking at head , we see that it takes [a] to a. Besides the concrete type array , it has no other information available 
and, therefore, its functionality is limited to working on the array alone. What could it possibly do with the variable a if it 
knows nothing about it? In other words, a says it cannot be a specific type, which means it can be any type, which leaves 
us with a function that must work uniformly for every conceivable type. This is what parametricity is all about. Guessing at 
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the implementation, the only reasonable assumptions are that it takes the first, last, or a random element from that array. 
The name head should tip us off. 


Here's another one: 


From the type signature alone, what could reverse possibly be up to? Again, it cannot do anything specific to a . It cannot 
change a toa different type or we'd introduce a b . Can it sort? Well, no, it wouldn't have enough information to sort every 
possible type. Can it re-arrange? Yes, | suppose it can do that, but it has to do so in exactly the same predictable way. 
Another possibility is that it may decide to remove or duplicate an element. In any case, the point is, the possible behaviour 
is massively narrowed by its polymorphic type. 


This narrowing of possibility allows us to use type signature search engines like Hoogle to find a function we're after. The 
information packed tightly into a signature is quite powerful indeed. 


Free as in theorem 


Besides deducing implementation possibilities, this sort of reasoning gains us free theorems. What follows are a few 
random example theorems lifted directly from Wadler'’s paper on the subject. 


if ts Hwcaud o: L ?@ a 


compose(f, head) == compose(head, map(f)); 


a - La j 


compose(map(f), filter(compose(p, f))) == compose(filter(p), map(f)); 


a4iAL 


You don't need any code to get these theorems, they follow directly from the types. The first one says that if we get the 
head of our array, then run some function f on it, that is equivalent to, and incidentally, much faster than, if we first map(f) 
Over every element then take the head of the result. 


You might think, well that's just common sense. But last | checked, computers don't have common sense. Indeed, they 
must have a formal way to automate these kind of code optimizations. Maths has a way of formalizing the intuitive, which is 
helpful amidst the rigid terrain of computer logic. 


The filter theorem is similar. It says that if we compose f and p to check which should be filtered, then actually apply 
the f via map (remember filter, will not transform the elements - its signature enforces that a will not be touched), it will 
always be equivalent to mapping our f then filtering the result with the p predicate. 


These are just two examples, but you can apply this reasoning to any polymorphic type signature and it will always hold. In 
JavaScript, there are some tools available to declare rewrite rules. One might also do this via the compose function itself. 
The fruit is low hanging and the possibilities are endless. 


Constraints 


One last thing to note is that we can constrain types to an interface. 


What we see on the left side of our fat arrow here is the statement of a fact: a must be an ord. Orin other words, a must 
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implement the ord interface. What is ord and where did it come from? In a typed language it would be a defined interface 
that says we can order the values. This not only tells us more about the a and what our sort function is up to, but also 
restricts the domain. We call these interface declarations type constraints. 


Here, we have two constraints: Eq and Show . Those will ensure that we can check equality of our as and print the 
difference if they are not equal. 


We'll see more examples of constraints and the idea should take more shape in later chapters. 


In Summary 


Hindley-Milner type signatures are ubiquitous in the functional world. Though they are simple to read and write, it takes time 
to master the technique of understanding programs through signatures alone. We will add type signatures to each line of 
code from here on out. 


Chapter 8: Tupperware 
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Tupperware 


The Mighty Container 





We've seen how to write programs which pipe data through a series of pure functions. They are declarative specifications 
of behaviour. But what about control flow, error handling, asynchronous actions, state and, dare | say, effects?! In this 
chapter, we will discover the foundation upon which all of these helpful abstractions are built. 


First we will create a container. This container must hold any type of value; a ziplock that holds only tapioca pudding is 
rarely useful. It will be an object, but we will not give it properties and methods in the OO sense. No, we will treat it like a 
treasure chest - a special box that cradles our valuable data. 


var Container = functiaon(x) { 
this. value = x; 


} 


Container.of = function(x) { return new Container(x); }; 


Here is our first container. We've thoughtfully named it container . We will use container .of as a constructor which saves 
us from having to write that god awful new keyword all over the place. There's more to the of function than meets the eye, 
but for now, think of it as the proper way to place values into our container. 


Let's examine our brand new box... 
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Container .of( ) 


Container .of ("hotdogs") 


wv 


Container .of (Container .of({name: "yoda"})) 


1 


If you are using node, you willsee { value: x} even though we've got ourselves a container(x) . Chrome will output the 
type properly, but no matter; as long as we understand what a container looks like, we'll be fine. In some environments 
you can overwrite the inspect method if you'd like, but we will not be so thorough. For this book, we will write the 
conceptual output as if we'd overwritten inspect as it's much more instructive than {_ value: x} for pedagogical as well 
as aesthetic reasons. 


Let's make a few things clear before we move on: 


® Container iS an object with one property. Lots of containers just hold one thing, though they aren't limited to one. 
We've arbitrarily named its property — value . 


e The _ value cannot be one specific type or our Container would hardly live up to the name. 


e Once data goes into the Container it Stays there. We could get it out by using ._ value , but that would defeat the 
purpose. 


The reasons we're doing this will become clear as a mason jar, but for now, bear with me. 


My First Functor 


Once our value, whatever it may be, is in the container, we'll need a way to run functions on it. 


(\d -- b) -- LOMCALIE C > LONCALNE! D 
Container.prototype.map = function(f){ 
return Container.of(f(this._ value) ) 


} 
Why, it's just like Array's famous map , except we have container a instead of [a] . And it works essentially the same way: 


Container .of(2).map(function(two){ return two + 2 }) 


— 


alt 


Container .of("flamethrowers").map(function(s){ return s.toUpperCase() }) 


Containe LAMETHROWERS ) 


Container .of("bombs").map(_.concat(' away')).map(_.prop('length' )) 
Container (10) 


We can work with our value without ever having to leave the container . This is a remarkable thing. Our value in the 
Container iS handed to the map function so we can fuss with it and afterward, returned to its container for safe keeping. 
As a result of never leaving the container , we can continue to map away, running functions as we please. We can even 
change the type as we go along as demonstrated in the latter of the three examples. 
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Wait a minute, if we keep calling map , it appears to be some sort of composition! What mathematical magic is at work 
here? Well chaps, we've just discovered Functors. 


A Functor is a type that implements map and obeys some laws 


Yes, Functor is simply an interface with a contract. We could have just as easily named it Mappable, but now, where's the 
fun in that? Functors come from category theory and we'll look at the maths in detail toward the end of the chapter, but for 
now, let's work on intuition and practical uses for this bizarrely named interface. 


What reason could we possibly have for bottling up a value and using map to get at it? The answer reveals itself if we 
choose a better question: What do we gain from asking our container to apply functions for us? Well, abstraction of function 
application. When we map a function, we ask the container type to run it for us. This is a very powerful concept, indeed. 


Schrddinger's Maybe 





Container is fairly boring. In fact, it is usually called Identity and has about the same impact as our id function(again 
there is a mathematical connection we'll look at when the time is right). However, there are other functors, that is, container- 
like types that have a proper map function, which can provide useful behaviour whilst mapping. Let's define one now. 


var Maybe = function(x) { 
this. value = x; 


} 


Maybe.of = function(x) { 
return new Maybe(x); 


} 
Maybe ..prototype.isNothing = function() { 

return (this. value === null || this.__value === undefinew); 
} 


Maybe .prototype.map = function(f) { 
return this.isNothing() ? Maybe.of(itull) : Maybe.of(f(this.__value)); 
} 


Now, Maybe looks a lot like container with one minor change: it will first check to see if it has a value before calling the 
supplied function. This has the effect of side stepping those pesky nulls as we map (Note that this implementation is 
simplied for teaching). 


Maybe .of ("Malkovich Malkovich") .map(match(/a/ig)); 


Y hafftat 
M a, }) 


Maybe .of (11) ) .map(match(/a/ig)); 
//>> Maybe(null) 


Maybe.of({name: "Boris"}).map(_.prop("age")).map(add(+~)), 
eee NAN het? 1u11) 
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\ 
} 


Maybe.of({name: "Dinah", age: ‘«}).map(_.prop("age")).map(add(- )); 


Notice our app doesn't explode with errors as we map functions over our null values. This is because maybe will take care 
to check for a value each and every time it applies a function. 


This dot syntax is perfectly fine and functional, but for reasons mentioned in Part 1, we'd like to maintain our pointfree style. 
As it happens, map is fully equipped to delegate to whatever functor it receives: 


al =Vieeale i > b Sof a> tab 
Hid o 8 FUulIUuluUul 1 \ a ] 
var map = curry(function(f, any_functor_at_all) { 
return any_functor_at_all.map(f); 


}); 


This is delightful as we can carry on with composition per usual and map will work as expected. This is the case with 
ramda's map as well. We'll use dot notation when it's instructive and the pointfree version when it's convenient. Did you 
notice that? I've sneakily introduced extra notation into our type signature. The Functor f => tellsus that f mustbea 
Functor. Not that difficult, but | felt | should mention it. 


Use cases 


In the wild, we'll typically see Maybe used in functions which might fail to return a result. 


a [a] -> Maybe( 

/ [ati cCmMeau so LL? ] Mayue\ 

var safeHead = function(xs) { 
return Maybe.of(xs[0]); 

}; 


var streetName = compose(map(_.prop('street')), safeHead, _.prop(‘addresses')); 


streetName({addresses: []}); 


(null) 
\ JUJL 


streetName({addresses: [{street: "Shady Ln.", number: 4201}]}); 


ady Ln.") 


safeHead is like Our normal _.head , but with added type safety. A curious thing happens when Maybe is introduced into our 
code; we are forced to deal with those sneaky null values. The safeHead function is honest and up front about its possible 
failure - there's really nothing to be ashamed of - and so it returns a Maybe to inform us of this matter. We are more than 
merely informed, however, because we are forced to map to get at the value we want since it is tucked away inside the 
Maybe Object. Essentially, this is a null check enforced by the safeHead function itself. We can now sleep better at night 
knowing a null value won't rear its ugly, decapitated head when we least expect it. Apis like this will upgrade a flimsy 
application from paper and tacks to wood and nails. They will guarantee safer software. 


Sometimes a function might return a Maybe(null) explicitly to signal failure. For instance: 


withdraw :: NuMD NT Maybe|(ACcount 
var withdraw = curry(function(amount, account) { 
return account.balance >= amount ? 
Maybe.of({balance: account.balance - amount}) : 
Maybe.of(null); 


}); 


Tini1si an | n ee AG IUNT > trir g 


var finishTransaction = compose(remainingBalance, updateLedger); 
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var getTwenty = compose(map(finishTransaction), withdraw(20)); 


getTwenty({ balance: 200.¢ }); 


wr 1a NRA 5 g @ Oe 


getTwenty({ balance: 19.0¢}); 


- lava 
Mayue \ilul. ) 


2 ae ee > 


withdraw will tip its nose at us and return Maybe(null) if we're short on cash. This function also communicates its 
fickleness and leaves us no choice, but to map everything afterwards. The difference is that the null was intentional here. 
Instead of a Maybe(String) , we get the Maybe(null) back to signal failure and our application effectively halts in its tracks. 
This is important to note: if the withdraw fails, then map will sever the rest of our computation since it doesn't ever run the 
mapped functions, namely finishTransaction . This is precisely the intended behaviour as we'd prefer not to update our 
ledger or show a new balance if we hadn't successfully withdrawn funds. 


Releasing the value 


One thing people often miss is that there will always be an end of the line; some effecting function that sends JSON along, 
or prints to the screen, or alters our filesystem, or what have you. We cannot deliver the output with return , we must run 
some function or another to send it out into the world. We can phrase it like a Zen Buddhist koan: “If a program has no 
observable effect, does it even run?". Does it run correctly for its own satisfaction? | suspect it merely burns some cycles 
and goes back to sleep... 


Our application's job is to retrieve, transform, and carry that data along until it's time to say goodbye and the function which 
does so may be mapped, thus the value needn't leave the warm womb of its container. Indeed, a common error is to try to 
remove the value from our Maybe one way or another as if the possible value inside will suddenly materialize and all will be 
forgiven. We must understand it may be a branch of code where our value is not around to live up to its destiny. Our code, 
much like Schrédinger's cat, is in two states at once and should maintain that fact until the final function. This gives our 
code a linear flow despite the logical branching. 


There is, however, an escape hatch. If we would rather return a custom value and continue on, we can use a little helper 
called maybe . 


maybe -«: Db -> b) MayO a D 
var maybe = curry(function(x, f, m) { 
return m.isNothing() ? x : f(m.__value); 


}); 
getTwenty :: Account rring 
var getTwenty = compose( 
maybe("“You're broke!", finishTransaction), withdraw(._ ) 
); 


getTwenty({ balance: 200.¢ }); 


JU DalanCce 1s $180.00 ; 


getTwenty({ balance: 10.0¢}); 


JU | 


. wu 


We will now either return a static value (of the same type that finishTransaction returns) or continue on merrily finishing up 
the transaction sans Maybe . With maybe , we are witnessing the equivalent of an if/else statement whereas with map , the 
imperative analog would be: if (x !== null) { return f(x) }. 


The introduction of Maybe can cause some initial discomfort. Users of Swift and Scala will know what | mean as it's baked 
right into the core libraries under the guise of option(al) . When pushed to deal with null checks all the time (and there 
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are times we know with absolute certainty the value exists), most people can't help, but feel it's a tad laborious. However, 
with time, it will become second nature and you'll likely appreciate the safety. After all, most of the time it will prevent cut 
corners and save our hides. 


Writing unsafe software is like taking care to paint each egg with pastels before hurling it into traffic; like building a 
retirement home with materials warned against by three little pigs. It will do us well to put some safety into our functions and 
Maybe helps us do just that. 


I'd be remiss if | didn't mention that the "real" implementation will split Maybe into two types: one for something and the 
other for nothing. This allows us to obey parametricity in map so values like null and undefined can still be mapped over 
and the universal qualification of the value in a functor will be respected. You'll often see types like some(x) / None or 
Just(x) / Nothing instead of a Maybe that does a null check on its value. 


Pure Error Handling 





It may come as a shock, but throw/catch is not very pure. When an error is thrown, instead of returning an output value, 
we sound the alarms! The function attacks, spewing thousands of 0's and 1's like shields & spears in an electric battle 
against our intruding input. With our new friend Either , we can do better than to declare war on input, we can respond with 
a polite message. Let's take a look: 


var Left = function(x) { 
this, _value = x; 


} 


Left.of = function(x) { 
return new Left(x); 


} 


Left .prototype.map - function(f) { 
return this; 


} 


var Right = function(x) { 
this. value = x; 


} 


Right .of = function(x) { 
return new Right(x); 


} 


Right .prototype.map = function(f) { 
return Right .of(f(this._value)); 


} 


Left and Right are two subclasses of an abstract type we call either . I've skipped the ceremony of creating the Either 
superclass as we won't ever use it, but it's good to be aware. Now then, there's nothing new here besides the two types. 
Let's see how they act: 
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Right .of ("rain").map(function(str){ return "b"+str; }); 


~ 


Left .of("rain").map(function(str){ return "b"+str; }); 


) 


Right .of({host: ‘localhost', port: 80}).map(_.prop('‘host')); 


( localhc st ) 


Left.of("rolls eyes...").map(_.prop("host")); 


Left is the teenagery sort and ignores our request to map Over it. Right will work just like container (a.k.a Identity). The 
power comes from the ability to embed an error message within the Left . 


Suppose we have a function that might not succeed. How about we calculate an age from a birth date. We could use 
Maybe(null) to Signal failure and branch our program, however, that doesn't tell us much. Perhaps, we'd like to know why it 
failed. Let's write this using Either . 


var moment require('moment'); 


getAge :: De jJse Either(String umber ) 
var getAge = curry(function(now, user) { 
var birthdate = moment(user.birthdate, 'YYYY-MM-DD'); 
if (!birthdate.isValid()) return Left.of("Birth date could not be parsed"); 
return Right .of(now.diff(birthdate, ‘years')); 


He 


getAge(moment(), {birthdate: '2005-12-12'}); 
"Right (9) 


™! 


getAge(moment(), 


lat+ 


birthdate: '20010704'}); 
te ld not be parsed") 


As 
( 


Now, just like maybe(null) , we are short circuiting our app when we return a teft . The difference, is now we have a clue 
as to why our program has derailed. Something to notice is that we return Either(String, Number) , Which holds a string 
as its left value and a Number aS itS Right . This type signature is a bit informal as we haven't taken the time to define an 
actual Either Superclass, however, we learn a lot from the type. It informs us that we're either getting an error message or 
the age back. 


fortune :: Number -> String 


var fortune = compose(concat("If you Survive, you will be "), add(-)); 


oy } 


2£Uildadl ee USC @ EC_Ltil 


var zoltar = compose(map(console.log), map(fortune), getAge(moment())); 


zoltar({birthdate: '2005-12-12'}); 
inf: you sur E Ou will be 160' 


RIQAT (und 


zoltar({birthdate: 'balloons! '}); 


4 ie = 4 ten - = r ha 
LErlL\ BL lLil Gale ould not De k 


When the birthdate is valid, the program outputs its mystical fortune to the screen for us to behold. Otherwise, we are 
handed a Left with the error message plain as day though still tucked away in its container. That acts just as if we'd 
thrown an error, but in a calm, mild manner fashion as opposed to losing its temper and screaming like a child when 
something goes wrong. 


In this example, we are logically branching our control flow depending on the validity of the birth date, yet it reads as one 
linear motion from right to left rather than climbing through the curly braces of a conditional statement. Usually, we'd move 
the console.log out of our zoltar function and map it at the time of calling, but it's helpful to see how the right branch 


Chapter 8: Tupperware 50 





mostly-adequate-guide 


differs. We use _ in the right branch's type signature to indicate it's a value that should be ignored(In some browsers you 
have to uS€ console.log.bind(console) to use it first class). 


I'd like to take this opportunity to point out something you may have missed: fortune , despite its use with Either in this 
example, is completely ignorant of any functors milling about. This was also the case with finishTransaction in the 
previous example. At the time of calling, a function can be surrounded by map , which transforms it from a non-functory 
function to a functory one, in informal terms. We call this process /ifting. Functions tend to be better off working with normal 
data types rather than container types, then /ifted into the right container as deemed necessary. This leads to simpler, more 
reusable functions that can be altered to work with any functor on demand. 


Either is great for casual errors like validation as well as more serious, stop the show errors like missing files or broken 
sockets. Try replacing some of the Maybe examples with either to give better feedback. 


Now, | can't help, but feel I've done Either a disservice by introducing it as merely a container for error messages. It 
Captures logical disjunction (a.k.a || ) ina type. It also encodes the idea of a Coproduct from category theory, which won't 
be touched on in this book, but is well worth reading up on as there's properties to be exploited. It is the canonical sum type 
(or disjoint union of sets) because its amount of possible inhabitants is the sum of the two contained types(I know that's a 
bit hand wavy so here's a great article. There are many things Either can be, but as a functor, it is used for its error 
handling. 


Just like with Maybe , we have little either , which behaves similarly, but takes two functions instead of one and a static 
value. Each function should return the same type: 


var either = curry(function(f, g, e) { 
Switch(e.constructor) { 
case Left: return f(e._ value); 
case Right: return g(e._ value); 


} 
}); 


-Witt& ss ww! = 


var zoltar = compose(consolt.log, either(id, fortune), getAge(moment())); 


zoltar({birthdate: '2005-12-12'}); 
f you survive, you will be 10 


undefined 


zoltar({birthdate: '‘balloons!'}); 
"Birth dé ould not be fF 


= , 4 
unger ined 


Finally, a use for that mysterious id function. It simply parrots back the value in the Left to pass the error message to 
console.log . We've made our fortune telling app more robust by enforcing error handling from within getage . We either 
slap the user with a hard truth like a high five from a palm reader or we carry on with our process. And with that, we're 
ready to move on to an entirely different type of functor. 


Old McDonald had Effects... 
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In our chapter about purity we saw a peculiar example of a pure function. This function contained a side-effect, but we 
dubbed it pure by wrapping its action in another function. Here's another example of this: 


// getFromStorage :: String -> (_ -> String) 
var getFromStorage = function(key) { 
return function() { 
return localStorage[key]; 


} 
} 


Had we not surrounded its guts in another function, getFromstorage would vary its output depending on external 
circumstance. With the sturdy wrapper in place, we will always get the same output per input: a function that, when called, 


will retrieve a particular item from localstorage . And just like that (maybe throw in a few Hail Mary's) we've cleared our 
conscience and all is forgiven. 


Except, this isn't particularly useful now is it. Like a collectable action figure in its original packaging, we can't actually play 
with it. If only there were a way to reach inside of the container and get at its contents... Enter ro. 


var IO = function(f) { 
this. value = f; 


} 


I0.of = function(x) { 
return new I0(function() { 
return x; 


te 
} 


I0.prototype.map = function(f) { 
return new I0(_.compose(f, this. value)); 


} 


10 differs from the previous functors in that the _ value is always a function. We don't think of its _ value as a function, 
however - that is an implementation detail and we best ignore it. What is happening is exactly what we saw with the 
getFromStorage example: ro delays the impure action by capturing it in a function wrapper. As such, we think of 10 as 
containing the return value of the wrapped action and not the wrapper itself. This is apparent in the of function: we have 
an 10(x) , the ro(function(){ return x }) iS just necessary to avoid evaluation. 


Let's see it in use: 
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var io_window = new I0(function(){ return window; }); 


10_window.map(function(win){ return win.innerWidth }); 


) 


i0_window.map(_.prop('location')).map(_.prop( ‘href')).map(split('/')); 


, ' £OCa st:8000", “blo 


$ :: String IQ 


var $ = function(selector) { 
return new I0(function(){ return document.querySelectorAll(selector); }); 


} 


$('#myDiv').map(head) .map(function(div){ return div.innerHTML; }); 


ah LU | SUTIC LIC! CELE 


Here, io_window iS an actual ro that we can map over Straight away, whereas $ Is a function that returns an ro after its 
called. I've written out the conceptual return values to better express the ro , though, in reality, it will always be { _ value: 
[Function] }. When we map over our 10, we stick that function at the end of a composition which, in turn, becomes the 
new _ value and so on. Our mapped functions do not run, they get tacked on the end of a computation we're building up, 
function by function, like carefully placing dominoes that we don't dare tip over. The result is reminiscent of Gang of Four's 
command pattern or a queue. 


Take a moment to channel your functor intuition. If we see past the implementation details, we should feel right at home 
Mapping over any container no matter its quirks or idiosyncrasies. We have the functor laws, which we will explore toward 
the end of the chapter, to thank for this pseudo-psychic power. At any rate, we can finally play with impure values without 
sacrificing our precious purity. 


Now, we've caged the beast, but we'll still have to set it free at Some point. Mapping over our ro has built up a mighty 
impure computation and running it is surely going to disturb the peace. So where and when can we pull the trigger? Is it 
even possible to run our ro and still wear white at our wedding? The answer is yes, if we put the onus on the calling code. 
Our pure code, despite the nefarious plotting and scheming, maintains its innocence and it's the caller who gets burdened 
with the responsibility of actually running the effects. Let's see an example to make this concrete. 


lee EO} es tring 
var url = new 10(function() { return window.location.href; }); 


L Atl LLvVb? 48ty J J 


var toPairs = compose(map(split('~')), split('&')); 


Fi Jai aillo as WL il poll atl 
r J i 


var params = compose(toPairs, last, split('?')); 


// finde ing IO Maybe [ ing ] 


var findParam = function(key) { 
return map(compose(Maybe.of, filter(compose(eq(key), head)), params), url); 


ie 


AF Tul it t Cali lilg da 


findParam("“searchTerm").__value(); 
// Maybe([ : ieee har 


Our library keeps its hands clean by wrapping url inan ro and passing the buck to the caller. You might have also 
noticed that we have stacked our containers; it's perfectly reasonable to have a Io(Maybe([{x])) , which is three functors 
deep( Array is most definitely a mappable container type) and exceptionally expressive. 
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There's something that's been bothering me and we should rectify it immediately: 10's — value isn't really its contained 
value, nor is it a private property as the underscore prefix suggests. It is the pin in the grenade and it is meant to be pulled 
by a caller in the most public of ways. Let's rename this property to unsafePerformIo to remind our users of its volatility. 


var IO = function(f) { 
this.unsafePerformIlo - f; 


} 


I0.prototype.map = function(f) { 
return new I0(_.compose(f, this.unsafePerfarmI0) ) ; 


} 


There, much better. Now our calling code becomes findParam("searchTerm") .unsafePer formI0() , Which ts clear as day to 
users (and readers) of the application. 


to will be a loyal companion, helping us tame those feral impure actions. Next, we'll See a type similar in spirit, but has a 
drastically different use case. 


Asynchronous Tasks 


Callbacks are the narrowing spiral staircase to hell. They are control flow as designed by M.C. Escher. With each nested 
callback squeezed in between the jungle gym of curly braces and parenthesis, they feel like limbo in an oubliette(how low 
can we go!). I'm getting claustrophobic chills just thinking about them. Not to worry, we have a much better way of dealing 
with asynchronous code and it starts with an "F”. 


The internals are a bit too complicated to spill out all over the page here so we will use Data.Task (previously Data.Future ) 
from Quildreen Motta's fantastic Folktale. Behold some example usage: 


var fs = require('fs'); 
eadFile :: String -> Task Error String 
var readFile = function(filename) { 
return new Task(function(reject, result) { 
fs.readFile(filename, ‘utf-8', function(err, data) { 
err ? reject(err) : result(data); 


}); 
}); 
}j 
readFile("metamorphosis").map(split('\n')).map(head) ; 
ask( "One morning, as Greg samsa was waking up fr 
Qu 
g SON :: String -> {} Task Error JSON 


var getJSON = curry(function(url, params) { 
return new Task(function(reject, result) { 
$.getJSON(url, params, result).fail(reject); 
}); 
}); 


getJSON('/video', {id: 10}).map(_.prop('title')); 


it ; C ei 


We can put normal, non futuristic values inside as 
Task.of(3).map(function(three){ return three + } }); 
) 


'as 


Chapter 8: Tupperware 54 





mostly-adequate-guide 


The functions I'm calling reject and result are our error and success callbacks, respectively. As you can see, we simply 
map over the task to work on the future value as if it was right there in our grasp. By now map should be old hat. 


If you're familiar with promises, you might recognize the function map aS then with task playing the role of our promise. 
Don't fret if you aren't familiar with promises, we won't be using them anyhow because they are not pure, but the analogy 
holds nonetheless. 


Like I0, Task will patiently wait for us to give it the green light before running. In fact, because it waits for our command, 
Io is effectively subsumed by Task for all things asynchronous; readFile and getJson don't require an extra 10 
container to be pure. What's more, task works ina similar fashion when we map over it: we're placing instructions for the 
future like a chore chart in a time capsule - an act of sophisticated technological procrastination. 


To run Our Task , we must call the method fork . This works like unsafePerformio , but as the name suggests, it will fork our 
process and evaluation continues on without blocking our thread. This can be implemented in numerous ways with threads 
and such, but here it acts as a normal async call would and the big wheel of the event loop keeps on turning. Let's look at 
fone. 


»: O MI 
— =~ 


vo te 


var blogPage = Handlebars.compile(blogTemplate) ; 


wus yr a 


reCnQer rage oo : > 


var renderPage = compose(blogPage, sortBy('‘date')); 


aavl 


Vly se Fal aula = 'qaSsA Cl L 


var blog = compose(map(renderPage), getJSON('/posts')); 


blog({}).fork( 
function(error){ $("#error").html(error.message); }, 
function(page){ $("#main").html(page); } 

); 


$('#spinner').show(); 


Upon calling fork , the Task hurries off to find some posts and render the page. Meanwhile, we show a spinner since 
fork does not wait for a response. Finally, we will either display an error or render the page onto the screen depending if 
the getJson call Succeeded or not. 


Take a moment to consider how linear the control flow is here. We just read bottom to top, right to left even though the 
program will actually jump around a bit during execution. This makes reading and reasoning about our application simpler 
than having to bounce between callbacks and error handling blocks. 


Goodness, would you look at that, task has also swallowed up Either ! It must do so in order to handle futuristic failures 
since our normal control flow does not apply in the async world. This is all well and good as it provides sufficient and pure 
error handling out of the box. 


Even with task , Our Io and cither functors are not out of a job. Bear with me on a quick example that leans toward the 
more complex and hypothetical side, but is useful for illustrative purposes. 
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dour: Comiig Eithe Url 
var dbUrl = function(c) { 
return (c.uname && c.pass && c.host && c.db) 
? Right .of("db:pg://"+c.unamet" : "+c .pass+"@"+c .host+"5432/"+c.db) 


: Left.of(Error("Invalid config!")); 


+h nr =e ee Tr) fre 
connectDb ee LOTT LY - CILLIICl cr?rofr (LU DbConnection) 


var connectDb = compose(map(Postgres.connect), dbUrl); 


jetConfig :: Filename -> Task Error (Either Error (10 DbConnection) ) 


J 


var getConfig = compose(map(compose(connectDb, JSON.parse)), readFile); 


Impure calling code 


getConfig("db.json").fork( 
logErr("couldn't read file"), either(console.log, map(runQuery) ) 


); 


In this example, we still make use of Either and 10 from within the success branch of readFile . Task takes care of the 
impurities of reading a file asynchronously, but we still deal with validating the config with Either and wrangling the db 
connection with ro. So you see, we're still in business for all things synchronous. 


| could go on, but that's all there is to it. Simple as map . 


In practice, you'll likely have multiple asynchronous tasks in one workflow and we haven't yet acquired the full container 
apis to tackle this scenario. Not to worry, we'll look at monads and such soon, but first, we must examine the maths that 
make this all possible. 


A Spot of Theory 


As mentioned before, functors come from category theory and satisfy a few laws. Let's first explore these useful properties. 


1genctity 


map(id) === id; 


compose(map(f), map(g)) === map(compose(f, g)); 


The identity law is simple, but important. These laws are runnable bits of code so we can try them on our own functors to 
validate their legitimacy. 


var idLaw1 = map(id); 
var idLaw2 = id; 


idLaw1(Container.of(2)); 


> LCUTILGLIICT | 2) 


idLaw2(Container.of(2)); 


alin 


You see, they are equal. Next let's look at composition. 


var compLaw1 = compose(map(concat(" world")), map(concat(" cruel"))); 
var compLaw2 = map(compose(concat(" world"), concat(" cruel"))); 


compLawi (Container .of("Goodbye")); 
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compLaw2 (Container .of ("Goodbye")); 


ainer(' world cruelGoc >) 


In category theory, functors take the objects and morphisms of a category and map them to a different category. By 
definition, this new category must have an identity and the ability to compose morphisms, but we needn't check because 
the aforementioned laws ensure these are preserved. 


Perhaps our definition of a category is still a bit fuzzy. You can think of a category as a network of objects with morphisms 
that connect them. So a functor would map the one category to the other without breaking the network. If an object a is in 
our source category c , when we map it to category po with functor F , we refer to that object as fF a (If you put it together 
what does that spell?!). Perhaps, it's better to look at a diagram: 


& e 
e eh 
a # 
x "RL ® 
n “e @ 
/ 
@ Ne ” 
J r 
oe. ® 
\ & e 
a © ® ® 


For instance, maybe maps our category of types and functions to a category where each object may not exist and each 
morphism has a null check. We accomplish this in code by surrounding each function with map and each type with our 
functor. We know that each of our normal types and functions will continue to compose in this new world. Technically, each 
functor in our code maps to a sub category of types and functions which makes all functors a particular brand called 
endofunctors, but for our purposes, we'll think of it as a different category. 


We can also visualize the mapping of a morphism and its corresponding objects with this diagram: 


q —— b 


ey F.of 


; wap (f) W 
Fa FO 





In addition to visualizing the mapped morphism from one category to another under the functor F , we see that the diagram 
commutes, which is to say, if you follow the arrows each route produces the same result. The different routes means 

different behavior, but we always end at the same type. This formalism gives us principled ways to reason about our code - 
we can boldly apply formulas without having to parse and examine each individual scenario. Let's take a concrete example. 
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// topRoute :: String -> Maybe String 
var topRoute = compose(Maybe.of, reverse); 


// bottomRoute :: String -> Maybe String 
var bottomRoute = compose(map(reverse), Maybe.of); 
topRoute("hi"); 


// Maybe("ih") 


bottomRoute("hi''); 
// Maybe("ih") 


Or visually: 


yi” reverseé “in a 


¥ map (reverse) . 
Maybe (“hv”) telltale Maybe (“th”) 


We can instantly see and refactor code based on properties held by all functors. 


Functors can stack: 


var nested = Task.of([Right.of ("pillows"), Left.of("no sleep for yaou")]); 


map(map(map(toUpperCase)), nested); 
// Task( (Right ("PILLOWS"), Left("no sleep for you")]) 


What we have here with nested is a future array of elements that might be errors. We map to peel back each layer and run 
our function on the elements. We see no callbacks, if/else's, or for loops; just an explicit context. We do, however, have to 
map(map(map(f))) . We can instead compose functors. You heard me correctly: 


var Compose = function(f_g x){ 
this.getCompose = f_g x; 


} 


Compose.prototype.map = function(f){ 
return new Compose(map(map(f), this.getCompose) ); 


} 


var tmd = Task.of(Maybe.of("Rock over Landan")) 
var ctmd = new Compase(tmd) ; 


map(concat(", rack on, Chicago"), ctmd); 
’ Campose(Task(Maybe("Rock over London, rock on, Chicago"))) 


ctmd.getCompose; 
// Task(Maybe("Rock over London, rock an, Chicago") ) 


There, one map . Functor composition is associative and earlier, we defined container , which is actually called the 
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Identity functor. If we have identity and associative composition we have a category. This particular category has 


Categories as objects and functors as morphisms, which is enough to make one's brain perspire. We won't delve too far into 


this, but it's nice to appreciate the architectural implications or even just the simple abstract beauty in the pattern. 


In Summary 


We've seen a few different functors, but there are infinitely many. Some notable omissions are iterable data structures like 


trees, lists, maps, pairs, you name it. eventstreams and observables are both functors. Others can be for encapsulation or 


even just type modelling. Functors are all around us and we'll use them extensively throughout the book. 


What about calling a function with multiple functor arguments? How about working with an order sequence of impure or 


async actions? We haven't yet acquired the full tool set for working in this boxed up world. Next, we'll cut right to the chase 


and look at monads. 


Chapter 9: Monadic Onions 


Exercises 


reqdiree’=./—./suppart  )= 
var Task = require('data.task'); 
var _ = require('ramda'); 


add(x,y) and map(f, x° ) ma a func 


auu| 


insic func 


var ex1 = undefined 


head g he: €: lemen fie ala 
var xs = Identity.of(['do', ‘ray', 'me', ‘fa', io dae ta de) 
var ex2 = undefined 
se SafeProp and head find the fi initial the us 
var safeProp - _.curry(function (x, 0) { return Maybe.of(o[x]); }); 


var user = { id: 2, name: "Albert" }; 


var ex3 = undefined 


var ex4 = function (n) { 
if (n) { return parseInt(n); } 


}; 


var ex4 = undefined 


Write a functT; Chat will g £ tnen foupc 
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77 QeEPGst <2 Int =>" Future( {ide “Int; title: string) 
var getPost = function (i) { 
return new Task(function(rej, res) { 
setTimeout (function( ){ 
res({id: i, title: ‘Love them futures'}) 
}, 30@) 
}); 


var exS = undefined 


// Exercise 6 

// ========== 

// Write a function that uses checkActive() and showWelcome() to grant access 
// or return the error 


var showWelcome = _.compose(_.add( "Welcome "), _.prop('name')) 


var checkActive = function(user) { 
return usSer.active ? Right.of(user) : Left.of('Your account is not active') 


} 


var ex6 = undefined 


// Exercise 7 

HS lei SSS 

// Write a validation function that checks for a length > 3. It should return 
// Right(x) if it is greater than 3 and Left("You need > 3") otherwise 


var ex7 = function(x) { 
return undefined // <--- write me. (don't be pointfree) 


// Exercise 8 

A, Sea aSasS=5 

// Use ex7 above and Either as a functor to save the user if they are valid or 
// return the error message string. Remember either's two arguments must return 
// the same type. 


var save = function(x){ 
return new I0(function(){ 
console.log("SAVED USER!"); 
return x + '-saved'; 
}); 
} 


var ex8 = undefined 
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Monadic Onions 


Pointy Functor Factory 


Before we go any further, | have a confession to make: | haven't been fully honest about that of method we've placed on 
each of our types. Turns out, it is not there to avoid the new keyword, but rather to place values in what's called a default 
minimal context. Yes, of does not actually take the place of a constructor - it is part of an important interface we call 
Pointed. 


A pointed functor is a functor with an of method 


What's important here is the ability to drop any value in our type and start mapping away. 


I0.of("tetris").map(concat(" master")); 
Be hele ee 


Maybe.of (1336) .map(add(i)); 


(1337) 


ray 


Task.of([{id: 2}, {id: 3}]).map(_.prop('‘id')); 
7 Task((2,3))) 


Either.of("The past, present and future walk into a bar...").map( 
concat("it was tense.") 


yi 


ent and r uture WaLlKkK LI i Bear ele eprom i ) 


If you recall, 10 and Task 's constructors expect a function as their argument, but maybe and Either donot. The 
motivation for this interface is a common, Consistent way to place a value into our functor without the complexities and 
specific demands of constructors. The term "default minimal context” lacks precision, yet captures the idea well: we'd like to 
lift any value in our type and map away per usual with the expected behaviour of whichever functor. 


One important correction | must make at this point, pun intended, is that Left.of doesn't make any sense. Each functor 
must have one way to place a value inside it and with Either , that's new Right(x) .Wedefine of using Right because if 
Our type can map , it Should map . Looking at the examples above, we should have an intuition about how of will usually 
work and Left breaks that mold. 


You may have heard of functions such as pure, point , unit , and return. These are various monikers for our of 
method, international function of mystery. of will become important when we start using monads because, as we will see, 
it's our responsibility to place values back into the type manually. 


To avoid the new keyword, there are several standard JavaScript tricks or libraries so let's use them and use of likea 
responsible adult from here on out. | recommend using functor instances from folktale , ramda Of fantasy-land as they 
provide the correct of method as well as nice constructors that don't rely on new. 


Mixing Metaphors 
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You see, in addition to space burritos (if you've heard the rumors), monads are like onions. Allow me to demonstrate with a 
common situation: 


‘/ Support 
l/h m= == = = = — — — — — — = = = — 
var fs = requiré('fs'); 


// readFile :: String -> 10 String 
var readFile = function(filename) { 
return new I0(function() { 
return fs.readFileSync(filename, ‘utf-8'); 


}); 
ia 


// print :: String -> IO String 
var print = function(x) { 
return new I0(function() { 
console.log(x); 
rerann x; 


}); 





// cat :: String -> IO (10 String) 
var cat = compose(map(print), readFile); 


cat(".git/config") 
// IO(1I0("[core]\nrepositoryformatversion = O\n")) 


What we've got here is an Io trapped inside another 10 because print introduced asecond ro during our map . To 
continue working with our string, we must map(map(f)) and to observe the effect, we must 


unsafePerfoarmI0().unsafePerformI0O() . 


cat :: String -> IO (10 String) 
var cat = compose(map(print), readFile); 


// catFirstChar :: String -> IO (IO String) 
var catFirstChar = campose(map(map(head)), cat); 
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catFirstChar(".git/config") 


While it is nice to see that we have two effects packaged up and ready to go in our application, it feels a bit like working in 
two hazmat suits and we end up with an uncomfortably awkward API. Let's look at another situation: 


safeProp :: Key {Key: a} Maybe a 
var safeProp = curry(function(x, obj) { 
return new Maybe(obj[x]); 


oe 


9a CMmoecau fae) Lo] ( yU 


var safeHead - safeProp(0); 


PLP SLAQUPFECSSOLIFCCtL .,. Us ?- Mdayvue May SC VQLIC ) 


var firstAddressStreet = compose( 
map(map(safeProp('street'))), map(safeHead), safeProp( addresses') 


); 
firstAddressStreet ( 

{addresses: [{street: {name: 'Mulburry', number: 8402}, postcode: "WC2N" }]} 
); 


a 7a Pe aaa ee a 
'Mulb nui ) 
aybe (Mai lan Mulbt 20 NO) 


Again, we see this nested functor situation where it's neat to see there are three possible failures in our function, but it's a 
little presumptuous to expect a caller to map three times to get at the value - we'd only just met. This pattern will arise time 
and time again and it is the primary situation where we'll need to shine the mighty monad symbol into the night sky. 


| said monads are like onions because tears well up as we peel back layer of the nested functor with map to get at the inner 
value. We can dry our eyes, take a deep breath, and use a method called join. 


var mmo = Maybe.of(Maybe.of('"nunchucks")); 
Maybe (! ("nunchucks") ) 


aybe (Mayb 
mmo.join(); 


Maybe ("nunchu 


var 1010 = I0.of(10.of("pizza")); 


IO(I0("pizza")) 
A \ t 


ioio.join() 
1O( pizza) 


\ t 


var ttt = Task.of(Task.of(Task.of("Sewers"))); 


ttt.join() 


'ao 


If we have two layers of the same type, we can smash them together with join . This ability to join together, this functor 
matrimony, is what makes a monad a monad. Let's inch toward the full definition with something a little more accurate: 


Monads are pointed functors that can flatten 


Any functor which defines a join method, has an of method, and obeys a few laws is a monad. Defining join is not too 
difficult so let's do so for Maybe : 


Maybe.prototype.join = function() { 
return this.isNothing() ? Maybe.of(null) : this. value; 


} 
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There, simple as consuming one's twin in the womb. If we have a Maybe(Maybe(x)) then ._ value will just remove the 
unnecessary extra layer and we can safely map from there. Otherwise, we'll just have the one Maybe as nothing would 
have been mapped in the first place. 


Now that we have a join method, let's sprinkle some magic monad dust over the firstAddressStreet example and see it 
in action: 


Ps ae " a + 
all a8 WihauU - i aa) = a 
J a 


var join = function(mma){ return mma.join(); } 


fi Ci ( »>SSOEFEeCT USer -> 
var firstAddressStreet = compose( 
join, map(safeProp('street')), join, map(safeHead), safeProp( ‘addresses’ ) 


); 
firstAddressStreet ( 

{addresses: [{street: {nmame: ‘Mulburry', number: 84°}, postcode: "WC2N" }]} 
); 


We added join wherever we encountered the nested Maybe 's to keep them from getting out of hand. Let's do the same 
with ro to give us a feel for that. 


I0.prototype.join = function() { 
return this.unsafePerformI0(); 


} 


Again, we simply remove one layer. Mind you, we have not thrown out purity, but merely removed one layer of excess 
shrink wrap. 


log :: a I0 a 
var log = function(x) { 
return new IO(function() { console .log(x); return x; }); 


} 


setStyle :: Selector -> CSSProps -> IO DOM 
var setStyle = curry(function(sel, props) { 
return new IO0(function() { return jQuery(sel).css(props); }); 


}); 


ge m2: String => 10) String 
var getItem = function(key) { 
return new I0(function() { return localStorage.getItem(key); }); 


Me 


applyPreferences :: String IO DOM 
var applyPreferences = compose( 
join, map(setStyle('#main')), join, map(log), map(/SO.parse), getItem 
); 


applyPreferences('preferences').unsafePerformI0O(); 
' Object {backgroundColor: "green"} 


<div style="background-color 


getItem returnS an I0 String SO We map to parse it. Both log and setStyle return ro ‘s themselves sO we must join to 
keep our nesting under control. 


My chain hits my chest 
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You might have noticed a pattern. We often end up calling join right after a map . Let's abstract this into a function called 


chain. 


// chain :: Monad m -> (a -> mb) ->ma->mb 
var chain = curry(function(f, m){ 
return m.map(f).join(); // or compose(join, map(f))(m) 


}); 


We'll just bundle up this map/join combo into a single function. If you've read about monads previously, you might have 
seen chain Called >>= (pronounced bind) or flatMap which are all aliases for the same concept. | personally think 
flatMap is the most accurate name, but we'll stick with chain as it's the widely accepted name in JS. Let's refactor the two 
examples above with chain: 


// map/join 
var firstAddressStreet = compose( 
join, map(safeProp('street')), join, map(safeHead), safeProp('addresses') 


ye 


chain 
var firstAddressStreet = compose( 
chain(safeProp('street')), chain(safeHead), safeProp('addresses') 


8 


// map/join 
var applyPreferences = compose( 
join, map(setStyle('#main')), join, map(log), map(JSON.parse), getItem 


ey 
// chain 


var applyPreferences = compose( 
chain(setStyle), chain(log), map(JSON.parse), getItem 


); 


| swapped out any map/join with our new chain function to tidy things up a bit. Cleanliness is nice and all, but there's 
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more to chain than meets the eye - it's more of tornado than a vacuum. Because chain effortlessly nests effects, we can 
Capture both sequence and variable assignment in a purely functional way. 


getJSON('/authenticate', {username: ‘stale', password: 'crackers'}) 
.chain(function(user) { 
return getJSON('/friends', {user_id: user.id}); 


}); 


querySelector("input .username").chain(function(uname) { 
return querySelector("input.email").chain(function(email) { 
return 10.of( 
"Welcome " + uname.value + " " + "prepare for spam at " + email.value 
); 
}); 
}); 


Maybe.of(3).chain(function(three) { 
return Maybe.of(2).map(add(three)); 


a 


Maybe .of (null).chain(safeProp('address')).chain(safeProp('street')); 
laybe(null); 


We could have written these examples with compose , but we'd need a few helper functions and this style lends itself to 
explicit variable assignment via closure anyhow. Instead we're using the infix version of chain which, incidentally, can be 
derived from map and join for any type automatically: t.prototype.chain = function(f) { return this.map(f).join(); }. 
We can also define chain manually if we'd like a false sense of performance, though we must take care to maintain the 
correct functionality - that is, it must equal map followed by join. An interesting fact is that we can derive map for free if 
we've created chain simply by bottling the value back up when we're finished with of . With chain , we can also define 
join aS chain(id) . It may feel like playing Texas Hold em’ with a rhinestone magician in that I'm just pulling things out of 
my behind, but, as with most mathematics, all of these principled constructs are interrelated. Lots of these derivations are 
mentioned in the fantasyland repo, which is the official specification for algebraic data types in JavaScript. 


Anyways, let's get to the examples above. In the first example, we see two Task 's chained in a sequence of asynchronous 
actions - first it retrieves the user , then it finds the friends with that user's id. We use chain to avoida 
Task(Task([Friend])) Situation. 


Next, we uS€ querySelector to find a few different inputs and create a welcoming message. Notice how we have access to 
both uname and email at the innermost function - this is functional variable assignment at its finest. Since ro is graciously 
lending us its value, we are in charge of putting it back how we found it - we wouldn't want to break its trust (and our 
program). 10.of is the perfect tool for the job and it's why Pointed is an important prerequisite to the Monad interface. 
However, we could choose to map as that would also return the correct type: 


querySelector("input .username").chain(function(uname) { 
return querySelector("input.email").map(function(email) { 
return "Welcome " + uname.value + " prepare for spam at " + email.value; 
}); 
}); 


Finally, we have two examples using maybe . Since chain iS mapping under the hood, if any value is null , we stop the 
computation dead in its tracks. 
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Don't worry if these examples are hard to grasp at first. Play with them. Poke them with a stick. Smash them to bits and 
reassemble. Remember to map when returning a “normal” value and chain when we're returning another functor. 


As a reminder, this does not work with two different nested types. Functor composition and later, monad transformers, can 
help us in that situation. 


Power trip 


Container style programming can be confusing at times. We sometimes find ourselves struggling to understand how many 
containers deep a value is or if we need map or chain (Soon we'll See more container methods). We can greatly improve 
debugging with tricks like implementing inspect and we'll learn how to create a "stack" that can handle whatever effects 
we throw at it, but there are times when we question if it's worth the hassle. 


I'd like to swing the fiery monadic sword for a moment to exhibit the power of programming this way. 


Let's read a file, then upload it directly afterward: 


Upt Odd os Veli ally = CaAliicl YL! 1nd } OUN ) 


var upload = compose (map(chain(httpPost(‘/uploads'))), readFile); 


Here, we are branching our code several times. Looking at the type signatures | can see that we protect against 3 errors - 
readFile USeS Either to validate the input (perhaps ensuring the filename is present), readFile may error when 
accessing the file as expressed in the first type parameter of Task , and the upload may fail for whatever reason which is 
expressed by the error in httpPost . We casually pull off two nested, sequential asynchronous actions with chain. 


All of this is achieved in one linear left to right flow. This is all pure and declarative. It holds equational reasoning and 
reliable properties. We aren't forced to add needless and confusing variable names. Our upload function is written against 
generic interfaces and not specific one-off apis. It's one bloody line for goodness sake. 


For contrast, let's look at the standard imperative way to pull this off: 


upload :: String (String 1) -> Vo 
var upload = function(filename, callback) { 
if (!filename) { 
throw "You need a filename!"; 
\elser, 
readFile(filename, function(err, contents) { 
if Cerne a cirow eles: 
httpPost(contents, function(err, json) { 
If (err) throw ent. 
callback(json); 
}); 
}); 
} 
} 


1 


Well isn't that the devil's arithmetic. We're pinballed through a volatile maze of madness. Imagine if it were a typical app that 
also mutated variables along the way! We'd be in the tar pit indeed. 


Theory 


The first law we'll look at is associativity, but perhaps not in the way you're used to it. 
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compose(join, map(join)) == compose(join, join) 


These laws get at the nested nature of monads so associativity focuses on joining the inner or outer types first to achieve 
the same result. A picture might be more instructive: 








M(M(M a)) map jouw)  mM(Ma) 
joln jouw 
hM(M a) a M a 


Starting with the top left moving downward, we can join the outer two m's of m(m(m a)) first then cruise over to our 
desired ™ a with another join . Alternatively, we can pop the hood and flatten the inner two ™'s with map(join) . We end 
up with the same ™ a regardless of if we join the inner or outer m's first and that's what associativity is all about. It's worth 
noting that map(join) != join. The intermediate steps can vary in value, but the end result of the last join will be the 


same. 


The second law is similar: 


// identity for all (M a) 
compose(join, of) == compose(join, map(of)) == id 


It states that, for any monad ™, of and join amounts to id.Wecanalso map(of) and attack it from the inside out. We 


Call this "triangle identity" because it makes such a shape when visualized: 


of map (of) 


Ma 








Ma M(M a) 


jon 


Ma 


If we start at the top left heading right, we can see that of does indeed drop our a in another ™ container. Then if we 
move downward and join it, we get the same as if we just called id in the first place. Moving right to left, we see that if 
we sneak under the covers with map and call of of the plain a, we'll stillend up with m (M a) and join ing will bring us 


back to square one. 


| should mention that I've just written of , however, it must be the specific m.of for whatever monad we're using. 
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Now, I've seen these laws, identity and associativity, somewhere before... Hold on, I'm thinking...Yes of course! They are 
the laws for a category. But that would mean we need a composition function to complete the definition. Behold: 


var mcompose = function(f, g) { 
return compose(chain(f), chain(g)); 


} 


4E7TC LUCHUITY 


mcompose(M, f) == f 


ay! A2UCTICL J 


mcompose(f, M) == f 


255 ic LV J y 
mcompose(mcompose(f, g), h) == mcompose(f, mcompase(g, h)) 


They are the category laws after all. Monads form a category called the "Kleisli category" where all objects are monads and 
morphisms are chained functions. | don't mean to taunt you with bits and bobs of category theory without much explanation 
of how the jigsaw fits together. The intention is to scratch the surface enough to show the relevance and spark some 
interest while focusing on the practical properties we can use each day. 


In Summary 


Monads let us drill downward into nested computations. We can assign variables, run sequential effects, perform 
asynchronous tasks, all without laying one brick in a pyramid of doom. They come to the rescue when a value finds itself 
jailed in multiple layers of the same type. With the help of the trusty sidekick "pointed", monads are able to lend us an 
unboxed value and know we'll be able to place it back in when we're done. 


Yes, monads are very powerful, yet we still find ourselves needing some extra container functions. For instance, what if we 
wanted to run a list of api calls at once, then gather the results? We can accomplish this task with monads, but we'd have to 
wait for each one to finish before calling the next. What about combining several validations? We'd like to continue 
validating to gather the list of errors, but monads would stop the show after the first Left entered the picture. 


In the next chapter, we'll see how applicative functors fit into the container world and why we prefer them to monads in 
many cases. 


Chapter 10: Applicative Functors 


Exercises 


var safeProp = _.curry(function (x, ao) { return Maybe.of(a[x]); }); 
var user = { 
ely 
name: "albert", 
address: { 
street: { 
number: 22, 
name: ‘Walnut St' 


} 
} 
}; 


var ex1 = undefined; 
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// Exercise 2 

, (== - === —=— 

// Use getFile to get the filename, remove the directory so it's just the file, 
// then purely log it. 


var getFile = function() { 
return new I0(function(){ return _filename; }); 


i 


var pureLog = function(x) { 
return new I0(function(){ 
console.log(x); 
return ‘logged ' + x; 
}); 
} 


var ex2 = undefined; 


// Exercise 3 
/ | ===== == 
// Use getPost() then pass the post's id to getComments(). 
uh 
Var getPost = function(1) < 
return new Task(function (rej, res) { 
setTimeout(function () { 
res({ adv 1, titles Love them tasks 9 4))7 
}, 300); 
}); 
} 


var getComments = function(i) { 
return new Task(function (rej, res) { 
setTimeout(function () { 
Gest 
{post_id: i, body: "This book should be illegal"}, 
{post_id: i, body: "Monads are like smelly shallots"} 
}); 
tae 8 OO) 
}); 
} 


var ex3 = undefined; 


77 EXenG ice 
—— 
// Use validateEmail, addToMailingList, and emailBlast to implement ex4's type 
// Signature. 


// addToMailingList :: Email -> I0([Email}) 
var addToMailingList = (function(list){ 
return function(email) { 
return new I0(function(){ 
list .push(email); 
retuna dist; 
}); 
} 
Cy 


function emailBlast(list) { 
return new IO(function(){ 
return ‘emailed: ' + list.join(','); 
}); 
} 


var validateEmail = function(x){ 
return x.match(/\S+@\S+\.\S+/) ? (mew Right(x)) : (new Left('invalid email')); 


i?) ex = Emails (Either String. | lOsstring) 
var ex4 = undefined; 


Chapter 9: Monadic Onions 


mostly-adequate-guide 


Applicative Functors 


Applying Applicatives 


The name applicative functor is pleasantly descriptive given its functional origins. Functional programmers are notorious 
for coming up with names like mappend or 1iftas , which seem perfectly natural when viewed in the math lab, but hold the 
clarity of an indecisive darth vader at the drive thru in any other context. 


Anyhow, the name should spill the beans on what this interface gives us: the ability to apply functors to each other. 


Now, why would a normal, rational person, such as yourself, want such a thing? What does it even mean to apply one 
functor to another? 


To answer these questions, we'll start with a situation you may have already encountered in your functional travels. Let's 
say, hypothetically, that we have two functors (of the same type) and we'd like to call a function with both of their values as 
arguments. Something simple like adding the values of two container S. 


walt &. Uu Lids WeEULauot LIS TiIUiWe!l oS aio wU 


add(Container.of( ), Container.of( )); 


L > US ul ruUSLY Na} 
var container_of_add_2 = map(add, Container.of( )); 


We have ourselves a Container with a partially applied function inside. More specifically, we have a container(add(2)) and 
we'd like to apply its add(2) tothe 3 in Container(3) to complete the call. In other words, we'd like to apply one functor to 
another. 


Now, it just so happens that we already have the tools to accomplish this task. We can chain and then map the partially 
applied add(2) like so: 


Container .of(2).chain(function(two) { 
return Container .of(3).map(add(two)); 


}); 


The issue here is that we are stuck in the sequential world of monads wherein nothing may be evaluated until the previous 
monad has finished its business. We have ourselves two strong, independent values and | should think it unnecessary to 
delay the creation of container(3) merely to satisfy the monad's sequential demands. 


In fact, it would be lovely if we could succinctly apply one functor's contents to another's value without these needless 
functions and variables should we find ourselves in this pickle jar. 


Ships in bottles 
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ap is a function that can apply the function contents of one functor to the value contents of another. Say that 5 times fast. 


Container .of(add(. )).ap(Container .of( )); 
Container (5) 


all together now 
Container .of(. ).map(add).ap(Container .of( )); 
' Container (5) 


There we are, nice and neat. Good news for container(3) as it's been set free from the jail of the nested monadic function. 
It's worth mentioning again that add , in this case, gets partially applied during the first map so this only works when add is 


curried. 


We can define ap like so: 


Container .prototype.ap = function(other_container) { 
return other_container.map(this. value); 


} 


Remember, this.__value will be a function and we'll be accepting another functor so we need only map it. And with that we 


have our interface definition: 
An applicative functor is a pointed functor with an ap method 
Note the dependence on pointed. The pointed interface is crucial here as we'll see throughout the following examples. 


Now, | sense your skepticism (or perhaps confusion and horror), but keep an open mind; this ap character will prove 
useful. Before we get into it, let's explore a nice property. 


F.of(x).map(f) == F.of(f).ap(F.of(x)) 


In proper English, mapping f is equivalent to ap ing a functor of f . Or in properer English, we can place x into our 
container and map(f) OR we can lift both f and x into our container and ap them. This allows us to write in a left-to-right 


fashion: 
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Maybe .of (add) .ap(Maybe.of(2)).ap(Maybe.of(3)); 


Waals Maybe 1) 


Task.of (add) .ap(Task.of(2)).ap(Task.of(3)); 
(5) 


One might even recognise the vague shape of a normal function call if viewed mid squint. We'll look at the pointfree version 
later in the chapter, but for now, this is the preferred way to write such code. Using of , each value gets transported to the 
magical land of containers, this parallel universe where each application can be async or null or what have you and ap will 
apply functions within this fantastical place. It's like building a ship in a bottle. 


Did you see there? We used Task in our example. This is a prime situation where applicative functors pull their weight. 
Let's look at a more in-depth example. 


Coordination Motivation 


Say we're building a travel site and we'd like to retrieve both a list of tourist destinations and local events. Each of these are 
separate, stand-alone api calls. 


ty 1 


var renderPage = curry(function(destinations, events) { render page */ }); 


1aSK{ Giv>some page with gest and vents G1iv> =) 


Task.of(renderPage) .ap(Http.get('/destinations')).ap(Http.get('/events')) 


Both Http calls will happen instantly and renderPage will be called when both are resolved. Contrast this with the monadic 
version where one Task must finish before the next fires off. Since we don't need the destinations to retrieve events, we 
are free from sequential evaluation. 


Again, because we're using partial application to achieve this result, we must ensure renderPage is Curried or it will not wait 
for both Tasks to finish. Incidentally, if you've ever had to do such a thing manually, you'll appreciate the astonishing 
simplicity of this interface. This is the kind of beautiful code that takes us one step closer to the singularity. 


Let's look at another example. 


var $ = function(selectoar) { 
return new I[0(function(){ return document .querySelector(selector) }); 


} 


VYvali pw | atl a4U wWJtei st 


var getVal = compose(map(_.prop('value')), $); 


| n 
'Y ) 2 & 


aeytls J & af L t 
var signIn = curry(function(username, password, remember_me){ / ir }) 


I0.of(signIn).ap(getVal('#email')).ap(getVal( '#password')).ap(I0.of(false)); 


Wye PRET. UU Si} 


signin iS a Curried function of 3 arguments so we have to ap accordingly. With each ap , signIn receives one more 
argument until it is complete and runs. We can continue this pattern with as many arguments as necessary. Another thing 
to note is that two arguments end up naturally in to whereas the last one needs a little help from of to lift it into 10 since 
ap expects the function and all its arguments to be in the same type. 
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Bro, do you even lift? 


Let's examine a pointfree way to write these applicative calls. Since we know map is equal to of/ap , we can write generic 
functions that will ap as many times as we specify: 


var liftA2 = curry(function(f, functor1, functor2) { 
return functor1.map(f).ap(functor2); 


}); 


var liftA3 = curry(function(f, functori, functor2, functor3) { 
return functor1.map(f).ap(functor2).ap(functor3) ; 


2 


lifta2 is a Strange name. It sounds like one of the finicky freight elevators in a rundown factory or a vanity plate for a 
cheap limo company. Once enlightened, however, it's self explanatory: lift these pieces into the applicative functor world. 


When | first saw this 2-3-4 nonsense it struck me as ugly and unnecessary, after all, we can check arity of functions in 
JavaScript and build this up dynamically. However, it is often useful to partially apply lifta(n) itself, so it cannot vary in 
argument length. 


Let's see this in use: 


] ne Fil 11] 

Ng ing 

/ ceréeareuser 2 Ena —-> Strang Tree ser 
var createUser = curry(function(email, name) { /* creating... */ }); 


Either .of(createUser).ap(checkEmail(user)).ap(checkName(user)); 


rat \ 
Le . tMVaeLllU EC ad ) 


liftA2(createUser, checkEmail(user), checkName(user) ); 


i ) 


Since createUser takes two arguments, we use the corresponding lifta2 . The two statements are equivalent, but the 
lifta2 version has no mention of either . This makes it more generic and flexible since we are no longer married to a 
specific type. 


Let's see the previous examples written this way: 


liftA2(add, Maybe.of(2), Maybe.of(3)); 
Nala ) 


liftA2(renderPage, Http.get('/destinations'), Http.get('/events')) 


badosKk\ -GLiV?7Ss0 page itn aest and events /div> ) 


liftA3(signiIn, getVal('#email'), getVal('#password'), I0.af(false)); 


my 


Operators 


In languages like haskell, scala, PureScript, and swift, where it is possible to create your own infix operators you may see 
syntax like this: 
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- haskell 


add <$> Right 2 <*> Right 3 


i. Crrine 
JavaScrip 


map(add, Right ( )).ap(Right(-)) 


It's helpful to know that <s> iS map (aka fmap ) and <*> is just ap . This allows for a more natural function application style 
and can help remove some parenthesis. 


Free can openers 





We haven't spoken much about derived functions. Seeing as all of these interfaces are built off of each other and obey a 
set of laws, we can define some weaker interfaces in terms of the stronger ones. 


For instance, we know that an applicative is first a functor, so if we have an applicative instance, surely we can define a 
functor for our type. 


This kind of perfect computational harmony is possible because we're working within a mathematical framework. Mozart 
couldn't have done better even if he had torrented ableton as a child. 


| mentioned earlier that of/ap is equivalent to map . We can use this knowledge to define map for free: 


map derived fron p 
X.prototype.map = function(f) { 
return this.constructor.of(f).ap(this); 


} 


Monads are at the top of the food chain, so to speak, so if we have chain , we get functor and applicative for free: 


Chapter 10: Applicative Functors 75 





mostly-adequate-guide 


Map dgerived from chain 
.prototype.map = function(f) { 
var m = this; 
return m.chain(function(a) { 
return m.constructor.of(f(a)); 


yy 


»x< 


ap dgerived Tro chan ap 
.prototype.ap = function(other) { 
return this.chain(function(f) { 
return other .map(f); 


}); 


»~< 


If we can define a monad, we can define both the applicative and functor interfaces. This is quite remarkable as we get all 
of these can openers for free. We can even examine a type and automate this process. 


It should be pointed out that part of ap 's appeal is the ability to run things concurrently so defining it via chain is missing 
out on that optimization. Despite that, it's good to have an immediate working interface while one works out the best 
possible implementation. 


Why not just use monads and be done with it, you ask? It's good practice to work with the level of power you need, no 
more, no less. This Keeps cognitive load to a minimum by ruling out possible functionality. For this reason, it's good to favor 
applicatives over monads. 


Monads have the unique ability to sequence computation, assign variables, and halt further execution all thanks to the 
downward nesting structure. When one sees applicatives in use, they needn't concern themselves with any of that 
business. 


Now, on to the legalities... 


Laws 


Like the other mathematical constructs we've explored, applicative functors hold some useful properties for us to rely on in 
our daily code. First off, you should know that applicatives are "closed under composition", meaning ap will never change 

container types on us(yet another reason to favor over monads). That's not to say we cannot have multiple different effects 
- we Can stack our types knowing that they will remain the same during the entirety of our application. 


To demonstrate: 


var tOfM = compose(Task.of, Maybe.of); 


liftA2(_.concat, tOfM('Rainy Days and Mondays'), tOfM(' always get me down')); 
oie 5 eo j ' 7 fleet ein 


‘DN- 


See, no need to worry about different types getting in the mix. 


Time to look at our favorite categorical law: identity: 


Identity 


ide 


peer anneniu == Vv 
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Right, so applying id all from within a functor shouldn't alter the value in v . For example: 


var v = Identity.of("Pillow Pets"); 
Identity.of(id).ap(v) == v 


Identity.of(id) makes me chuckle at its futility. Anyway, what's interesting is that, as we've already established, of/ap is 
the same as map So this law follows directly from functor identity: map(id) == id. 


The beauty in using these laws is that, like a militant kindergarten gym coach, they force all of our interfaces to play well 
together. 


Homomorphism 


teed bares : 
' riitcotl 


Aan CGMan@nOncon) == A.of (f(x)) 


A homomorphism is just a structure preserving map. In fact, a functor is just a homomorphism between categories as it 
preserves the original category's structure under the mapping. 


We're really just stuffing our normal functions and values into a container and running the computation in there so it should 
come as no Surprise that we will end up with the same result if we apply the whole thing inside the container (left side of the 
equation) or apply it outside, then place it in there (right side). 


A quick example: 


Either.of(_.toUpper).ap(Either.of("oreos")) == Either.of(_.toUpper("oreos")) 


Interchange 


The interchange states that it doesn't matter if we choose to lift our function into the left or right side of ap . 


ATILOUI UVIIGit 


eetemCHOon == A.of(function(f) { return f(x) }).ap(v) 
Here is an example: 


var v = Task.of(_.reverse); 
var x = '‘Sparklehorse'; 


v.ap(Task.of(x)) == Task.of(function(f) { return f(x) }).ap(v) 


Composition 


And finally composition which is just a way to check that our standard function composition holds when applying inside of 
containers. 


1tion 


A.of (compose) .ap(u).ap(v).ap(w) == u.ap(v.ap(w)); 
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var u = I0.of(_.toUpper); 
var v = I0.of(_.concat("& beyond')); 
var w = I0.of("blood bath "); 


I0.of(_.compose).ap(u).ap(v).ap(w) == u.ap(v.ap(w)) 


In Summary 


A good use case for applicatives is when one has multiple functor arguments. They give us the ability to apply functions to 


arguments all within the functor world. Though we could already do so with monads, we should prefer applicative functors 


when we aren't in need of monadic specific functionality. 


We're almost finished with container apis. We've learned how to map, chain , and now ap functions. In the next chapter, 


we'll learn how to work better with multiple functors and disassemble them in a principled way. 


Chapter 11: Traversable/Foldable Functors 


Exercises 


require('./support'); 
var Task = require('data.task'); 
Var. = require( randa’ ); 


// fib browser for test 
var localStorage = {}; 


Write function that add's two possibly null numbers together using Maybe and ap() 


//  ex1 :: Number -> Number -> Maybe Number 
var exi = function(x, y) { 


// write m 


}; 
ea 
Now write a function that takes 2 Maybe's and adds then 
GAZ =: Maybe Numbe -? MaYVEe Number -2 Maybe NUMDE fT 


var ex2 = undefined; 


shine . . / Apt ay eae Gs CeO Ca aah Star asp 2 Sere seh 4 a es Paine 
Run both getPost(n) and getComments(n) then render the page with both. (the n arg is arbitrary) 


var makeComments = _.reduce(function(acc, c){ return acct"<li>"+c+"</1i>" }, yy 


var render = _.curry(function(p, cs) { return "<div>"+p.title+'</div>"+makeComments(cs); }); 


// ex3 :: Task Error HTML 
var ex3 = undefined; 


/ Exercise 4 
// Write an IO that gets both player1 and player2 from the cache and st t game 
localStorage.player1 = "toby"; 


localStorage.player2 = "sally"; 


var getCache = function(x) { 
return new IO(function() { return localStorage[x]; }); 
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} 


var game = _.curry(function(pi, p2) { return p1 + ' vs ' + p2; }); 


{i ex4 72 TO String 
var ex4 = undefined; 


// TEST HELPERS 
[/ z2222222=222=========- 





function getPost(i) { 
return new Task(function (rej, res) { 


setTimeout(function () { res({ id: i, title: 'Love them futures' }); }, 300); 


}); 
} 


function getComments(i) { 
return new Task(function (rej, res) { 
setTimeout(function () { 
res({"This book should be illegal", 
}, 300); 
}); 
} 
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